ITK/Rules for CVS Contributors

This page is intended for developers who have gained CVS write access to the toolkit.

It collects many of the behavior guidelines that have been developed in the ITK community over the years. By stating the rules here we are hopping to make easier for new CVS contributor to know how to perform different tasks.

Release Process

ITK is released every four months.

The release process involves

1. Select contributions from the Insight Journal
2. Move them to the Code/Review directory
3. Select code that has been in the Review directory for more than one release and move it to its permanent location.

Freezing

The freezing process involves removing CVS write access from the majority of developers and reducing the active writers to 3 or 4 developers.

During the freezing period, only bug fixes are supposed to be added to the code in the repository.

Contributing New Classes

New classes are contributed through the Insight Journal

Developers with CVS write access should not commit new files to the toolkit directly. All new classes must be submitted first as contributions to the Insight Journal

Release Branches

After a release is made, a single developer, the 'Gatekeeper' is designated as the only one allowed to commit code changes to the branch.

The code changes in a branch are subject to the following rules

• Only bug fixes should be committed
  • The bug fix should have been already demonstrated in the main CVS trunk in at least a Nightly Dashboard build with multiple platforms
• The bug must be logged in the bugtracker as a bug specific to that release branch, and must be assigned to the Gatekeeper
• The Gatekeeper must maintain a Nightly submission to the Dahsboard for that specific release branch.
• The Gatekeeper will test the bug fix in the branch, by submitting an Experimental build
• After the Experimental build proves to be successful, the Gatekeeper will commit the changes, making sure that a branch tagged CVS checkout is used.
• The commit CVS message must include the bug number so that in the future, developers can refer to the bug tracker for an explanation on the justification for these changes.
• After committing the changes, the Gatekeeper must check with the developers list on whether that changes (or the cumulation of previous changes) justify to tag a patch version of the release branch.
  • If it does, then the Gatekeeper will tag the branch with the appropriate patch number, will generate new tarballs and will post them in Sourceforge and in the FTP directory at Kitware.
• At that point the Gatekeeper will close the bug entry in the bugtracker.