|
|
| (2 intermediate revisions by one other user not shown) |
| Line 1: |
Line 1: |
| __TOC__
| | This page previously contained information about ITK development with CVS. |
| | | The old information has been removed to avoid confusion after development moved to Git. |
| This page is intended for developers who have gained CVS write access to the toolkit. | | Please [[ITK/Git|get started here]] instead. |
| | |
| 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 | |
| | |
| # Select contributions from the Insight Journal
| |
| # Move them to the Code/Review directory
| |
| # 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.
| |
