NOTE: This is work in progress!!

This document is intended to capture some of the policies we would like all committers to follow when it comes to checking in changes into our SVN tree.

Trunk

Trunk is CTR, Commit-Then-Review,  policy. This was discussed and voted on by the community a long time ago. This does grant a lof of freedom to committing experimental or unstable code to the trunk. However, with such powers, comes some responsibilities:

1. You are responsible for latest trunk to build and at least start up with your changes before you commit to SVN. This typically implies that you ought to do an "svn up" to your tree and build before committing. Of course, we don't expect everyone to test on more than their preferred development platform(s), and we'll work with the Infraops team to increase our coverage with continuous integration tools and build-bots.
2. If the trunk is broken (i.e. it doesn't build and/or run even without your changes), please don't commit! Meaning, please don't pour more fuel to the fire, doing so will just complicate resolving the previous commit(s) that might have broken the build.
3. If your changes are so large that you want to make partial commits, please create a SVN branch or work on a local repository using a VCS system like Git or Mercurial. Several of the developers in the community use Git and hg, and can provide tips on how to use it.

Release branches

All release branches (e.g. 2.0.x) should always be kept in a stable and functional state. The commit policy is RTC, Review Then Commit, and backporting changes from trunk should be voted on via the STATUS file on the respective branches.