Rules for GDCM Contributors

From GDCM Wiki
Jump to: navigation, search

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

It collects many of the behavior guidelines that have been developed in the VTK & ITK communities over the years, GDCM derives from those.



Developers are expected to become familiar with the following tools:

  • Doxygen
  • GIT
  • bug tracker
  • CMake
    • CTest
    • CDash
  • patch / git diff


doxygen is bit picky somtime, and developers should follow some rules to be sure there comment are included in the documentation:

Use /// or /** */

Example 1:

/// Set/Get Slope Intercept

Example 2:

 * This function..
 * bla bla

When documenting a class, make sure the doxygen comment is right next to the class declaration:

// This comment will not be part of the documentation
 * \brief MyClass
 * \note this class is a class
class GDCM_EXPORT MyClass {};


GIT config file

See the Git page.

GIT commit comment

It is a good idea to specify what type of commit you are doing, basically there are 5 type:

  • ENH: You are adding a new feature to GDCM
  • DOC: You are adding/fixing documentation in GDCM
  • STYLE: Cosmetic patch (indentation, style convention)
  • COMP: Fix a compilation issue (usually very compiler specific)
  • FIX: Fix a bug, seg fault
  • BUG: (idem FIX)

Typically a compilation warning fix, will be in 'STYLE'.


$ git commit -m"ENH: Adding MPEG2 Codec to GDCM"

GIT patch

It is a good idea to send patch to the gdcm-hackers mailing list to discuss a point. Instead of sending large file, only sent the diff between your source (could be a particular tag), using the git diff command:

$ git diff > /tmp/gdcm.patch

See also the specific page: Git/Patches

Applying a patch

Using the patch command:

$ patch -p0 < /tmp/gdcm.patch

Unix patch are easy to read:

+ line: line added
- line: line removed

Release Process

GDCM does not have a fix schedule.

The release process involves

  1. Check the nightly dashboard is green
  2. Merge change from master to release branch branch
  3. Check the nightly dashboard for release is green
  4. Tag the gdcm VERSION (tag repository)

Which means that any patch applied to GDCM should first go to master, then release branch then a tag. The reasoning is quite simple, we have more dashboard running on the gdcm master, fewer on branch and none on a specific tags, since by definition the source code is not evolving.

Scientific Study of Debian Governance

Recent scholarship on open source communities suggests that any governance system introduced must be meritocratic
in order to attract high quality contributions from voluntary members.
By rewarding merit with greater status, responsibility, or opportunities to enhance their own development,
production communities can satisfy a contributor’s need for recognition and reward in ways that their work lives may no.

GDCM: [Welcome | Site Map]
Personal tools