VTK/Commit Guidelines

• Follow the VTK Coding Standards when writing new code or modifying existing code

• Do not commit 3rd party code that is compiled and linked in by default unless it conforms to VTK's BSD-style license. For example GPL and LGPL do not conform to a BSD license.

• Build into a fresh empty binary directory after making your last code change

• Run ctest in your binary directory and make sure all the VTK tests pass before committing your code

• If possible, move your changes to another platform or compiler and verify that they work there also

• If possible, use an older compiler to verify that you are not relying on newer features or C++ constructs only handled by newer versions of compilers or platform libraries. Visual Studio 6 and gcc 2.95 are still supported platforms for VTK. Your code must build and test cleanly on these platforms to pass all the nightly dashboards.

• Commit your changes as early in the day as possible, preferably before 12:00 noon Eastern time. If it's after that time, strongly consider waiting until first thing next morning. There should not be a rush when committing code to VTK. It's better to commit changes early so that you have time to respond to continuous dashboard failures before the slew of nightly dashboards runs.

• Do NOT commit code after 12:00 noon Eastern time unless it is to address a continuous dashboard failure introduced by a commit that you did before 12:00 noon Eastern time.

• Commit the entire tree in one call to cvs commit. Do not call commit on some files in one directory and then others in another directory. The continuous dashboards might pick up one set of changes and report failures because the second set of changes is necessary to avoid the failures (configure, build or test issues...). You can avoid this by always doing a top level commit of everything related to the checkin all at once.

• Observe the continuous dashboards for the remainder of the day after your commit

• Observe the nightly dashboards the day following your commit

• Fix any warnings, errors or test failures related to your commit as soon as possible after becoming aware of them. If they are too difficult to fix quickly or you don't have time to restore the dashboards to green, then back out your changes until you do have time. If you don't, somebody else will do it for you... :-)