ITK/Rules for CVS Contributors: Difference between revisions

From KitwarePublic
< ITK
Jump to navigationJump to search
Line 42: Line 42:
= Release Branches =
= 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 latest release is managed in the Git repository on the '''release''' branch.
 
Thanks to Git anyone can check out this branch locally and create commits to fix bugs.
The code changes in a branch are subject to the following rules
See the ITK Git page section on how to contribute a [[ITK/Git#Release_Bug_Fix|Release Bug Fix]].
 
Bug fix topics should be started on the '''release''' branch but merged to the '''master''' branch.
* Only bug fixes should be committed
A release manager will handle merging the topic back to the '''release''' branch.
** 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.

Revision as of 17:49, 12 October 2010

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.

Tools

Developers are expected to become familiar with the following tools:

  • KWStyle
  • Doxygen
  • CVS
  • MANTIS bug tracker
  • CMake
    • CTest
  • patch / cvs diff

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

The latest release is managed in the Git repository on the release branch. Thanks to Git anyone can check out this branch locally and create commits to fix bugs. See the ITK Git page section on how to contribute a Release Bug Fix. Bug fix topics should be started on the release branch but merged to the master branch. A release manager will handle merging the topic back to the release branch.

Retrieved from "https://public.kitware.com/Wiki/index.php?title=ITK/Rules_for_CVS_Contributors&oldid=31852"