Development Workflow

This page summarizes the development workflow that was agreed upon at the ParaView Summit. The goal of this workflow is to organize ParaView development process making it easier for various projects contributing to ParaView to coordinate with each other as well as the release cycle.

The bug-tracker serves as the central tool that drives the process.

• A project is created for every customer/development team contributing to ParaView.
• Every task is must be reported as bug. When a issue is reported, if the issue is originating from a particular customer, the reporter will assign the issue to a particular project or leave it unassigned. If a customer gets interested in an issue, he can assign the issue to his project.
• A issue then moves over different states as described in the figure below:

• The bug reporting page also gets simplified as follows:

State Transitions

• (new) ==> backlog: A bug enter the bug tracker in the "backlog" state. This is default state indicating that the bug has been noted.

• backlog ==> expired: If a bug has no activity for 6 months, it automatically gets marked as expired. An issue in expired state indicates that there was no enough interest to get the bug resolved.

• expired ==> backlog: If the reporter or some other developer or manager gets interested in the issue, he can always re-open it by moving it to backlog. There it will again have a 6 month timeout to be addressed or will be timed-out.

• backlog <==> todo: Managers (and Developers) can periodically select a subset of bugs from the backlog to be addressed in the near future (say month or so). These get moved to the "todo" state. Of course, they can always out those issues back to backlog if deemed necessary due to workload or changed priorities. Ideally, there should not be more that 3-5 bugs per active developer for a project in the todo state.

• todo <==> active-development: When a developer starts working on an issue, he moves the bug to the "active-development" state (and back if he decides to postpone the work for later). "active-development" state helps everyone get an idea of what the developers are actively working on.

• active-development ==> gatekeeper-review: Once the developer is done with the feature and has merged the topic branch to "next", he can change the state to gatekeeper-review. Gatekeeper's role is to verify the commit, ascertain that it does not break the dashboard and then merge the topic to "master". Thus no topics can be merged to "master" until they have undergone gatekeeper review. Gatekeepers will be a team a Kitware responsible for the well-being of the application.

• gatekeeper-review ==> todo: If the developer himself or the gatekeeper notices issues with the topic, it is not merged into "master" and pushed back to "todo" for further work.

• gatekeeper-review ==> customer-review: Once the gatekeeper is satisfied with the fix, the topic gets merged into "master" (if applicable) and the bug is pushed forward for "customer-review". At this point, the customer, if any, for the project can test the feature/bug.

• customer-review ==> backlog : if the customer is not satisfied with the fix, he can push the bug back to backlog.

• customer-review ==> closed : if the customer is satisfied with the fix, it gets marked closed.

• closed ==> backlog : this provides a means to reopen old, previously addressed bugs that resurface at later point in time.