VTK/Commit Guidelines: Difference between revisions

From KitwarePublic
< VTK
Jump to navigationJump to search
No edit summary
(Clarified how data should be pushed for baselines etc.)
 
(5 intermediate revisions by 3 users not shown)
Line 7: Line 7:
* Run ctest in your binary directory and make sure '''all''' the VTK tests pass before committing your code
* 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
* After pushing your changes to Gerrit for review, check the CDash@Home submissions linked to from the topic
** These should be clean, apart from any altered baseline images


* 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.
* Your code must build and test cleanly on these platforms to pass all the nightly dashboards


* For large commit (eg. update of tiff library, addition of a brand new library, refactoring of numerous classes in VTK), it is usally a good idea to send an email to the vtk-developers mailing list.
* For large commit (eg. update of tiff library, addition of a brand new library, refactoring of numerous classes in VTK), it is a good idea to send an email to the vtk-developers mailing list.


* 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.
* Try to make a logical topic, where each change is functional, use 'git commit --amend'' and/or interactive rebase to clean up a topic before pushing it


* 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.
* Push your changes to [[VTK/Git/Develop|Gerrit for review]], following the [[VTK/Git|instructions here]]
 
** Any new baseline images will be automatically uploaded when the topic is pushed for review, see [[VTK/Git/Develop/Data#Push|this note]] for more details.
* 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.
** For any changed baseline images, update the md5 file in the source code. For example, if the <code>TestScalarBarCombinatorics.png</code> baseline (created by <code>vtkRenderingMatplotlibCxxTests</code>) changes, then <code>Rendering/Matplotlib/Testing/Data/Baseline/TestScalarBarCombinatorics.png.md5</code> should be changed to match the md5 sum of the image you upload to Midas. This commit should be pushed to Gerrit along with the changes that alter the baseline.
** Don't rush committing your code, select reviewers and respond to their feedback.
** Check the CDash@Home submissions linked to from the topic.


* Observe the continuous dashboards for the remainder of the day after your commit
* Observe the continuous dashboards for the remainder of the day after your commit
Line 27: Line 30:
==More tips to avoid failures==
==More tips to avoid failures==


* Make sure you run all the tests before you commit (At a command
* Make sure you run all the tests before you commit (at a command prompt in your build directory, type 'ctest', assuming that the cmake and ctest executable directories are in your path).
prompt in your build directory, type 'ctest', assuming that the cmake
and ctest executable directories are in your path).


* Turn Tcl wrapping on. About half of the tests in VTK are in Tcl.
* Turn Python wrapping on. About half of the tests in VTK are in Python
Note that if you are building ParaView, the Tcl wrapping is forced to
off. You have to build another versions of VTK to get the Tcl
wrapping.


* It might also help to build with MPI and also to set
* It might also help to build with MPI
PYTHON_EXECUTABLE (some tests depend on python)


* Compile code with options like the following gcc options to catch warnings:
* Compile code with VTK_EXTRA_COMPILER_WARNINGS enabled so spot new compiler warnings
-Wall -W -Wunused-variable -Wunused-parameter -Wunused-function -Wunused -Woverloaded-virtual


* If you add something to VTK, add a test for it as well
* If you add something to VTK, add a test for it as well


* It is good to test on 64 bit machines to draw out potential problems
* It is also good to test vtkIdType as both 32 bit and 64 bits (toggled with the VTK_USE_64BIT_IDS CMake option
 
* It is also good to test vtkIdType as both 32 bit and 64 bits
(toggled with the VTK_USE_64BIT_IDS CMake option.
 
* Make sure Tcl wrappers work for your code (in both VTK and
vtkSNL) - wrap header file statements with //BTX and //ETX to tell the
wrapper to ignore them
 
* Kitware has a particular tab and spacing format for their code -
see documentation
 
* Mixing floats and doubles in computation is bad - this is
something that isn't actually tested for but if someone at Kitware
notices it they'll ask you to change it - they prefer to do everything
with doubles when possible


* Your classes need to have a "PrintSelf()" method that prints out
* Make sure the Python wrappers work for your code (in both VTK)
your variables (check if they're NULL first), or else you will get test failures.


* Aren't allowed to define copy constructors/operators - instead
* Mixing floats and doubles in computation is bad
create a "Copy()" method or something similar. In fact, you should
always declare the "default" copy constructors and operators as
private and never implement them.


* It's good to commit changes to cvs in the morning because if
* Your classes need to have a "PrintSelf()" method that prints out your variables (check if they're NULL first), or else you will get test failures
they're committed late in the day, people at Kitware will actually
stick around to make sure there are no problems


* Do separate testing for VTK additions since ParaView tests that
* You are not allowed to define copy constructors/operators - instead create a "Copy()" method or something similar
use them don't count
** You should always declare the "default" copy constructors and operators as private and never implement them


* Prefix commit messages with the following when committing code to
* Prefix commit messages with the following when committing code to VTK or ParaView:
VTK or ParaView:
  ENH: Feature Implementation
  ENH: Feature Implementation
  BUG: Bug fix
  BUG: Bug fix

Latest revision as of 17:10, 28 June 2013

  • 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
  • After pushing your changes to Gerrit for review, check the CDash@Home submissions linked to from the topic
    • These should be clean, apart from any altered baseline images
  • Your code must build and test cleanly on these platforms to pass all the nightly dashboards
  • For large commit (eg. update of tiff library, addition of a brand new library, refactoring of numerous classes in VTK), it is a good idea to send an email to the vtk-developers mailing list.
  • Try to make a logical topic, where each change is functional, use 'git commit --amend and/or interactive rebase to clean up a topic before pushing it
  • Push your changes to Gerrit for review, following the instructions here
    • Any new baseline images will be automatically uploaded when the topic is pushed for review, see this note for more details.
    • For any changed baseline images, update the md5 file in the source code. For example, if the TestScalarBarCombinatorics.png baseline (created by vtkRenderingMatplotlibCxxTests) changes, then Rendering/Matplotlib/Testing/Data/Baseline/TestScalarBarCombinatorics.png.md5 should be changed to match the md5 sum of the image you upload to Midas. This commit should be pushed to Gerrit along with the changes that alter the baseline.
    • Don't rush committing your code, select reviewers and respond to their feedback.
    • Check the CDash@Home submissions linked to from the topic.
  • 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... :-)

More tips to avoid failures

  • Make sure you run all the tests before you commit (at a command prompt in your build directory, type 'ctest', assuming that the cmake and ctest executable directories are in your path).
  • Turn Python wrapping on. About half of the tests in VTK are in Python
  • It might also help to build with MPI
  • Compile code with VTK_EXTRA_COMPILER_WARNINGS enabled so spot new compiler warnings
  • If you add something to VTK, add a test for it as well
  • It is also good to test vtkIdType as both 32 bit and 64 bits (toggled with the VTK_USE_64BIT_IDS CMake option
  • Make sure the Python wrappers work for your code (in both VTK)
  • Mixing floats and doubles in computation is bad
  • Your classes need to have a "PrintSelf()" method that prints out your variables (check if they're NULL first), or else you will get test failures
  • You are not allowed to define copy constructors/operators - instead create a "Copy()" method or something similar
    • You should always declare the "default" copy constructors and operators as private and never implement them
  • Prefix commit messages with the following when committing code to VTK or ParaView:
ENH: Feature Implementation
BUG: Bug fix
STYLE: Coding style change (indenting, braces, non-bug or feature change)
CMP: Fixed compiler error or warning
DOC: Changed a comment



VTK: [Welcome | Site Map]