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.
TS-#### short summary (50 chars or less), not a sentence More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together. |
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:
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. At a minimum the the build should not break on the current primary buildbot slave which is http://ci.apache.org/buildslaves/bb-vm_ubuntu (Ubuntu Linux). If the primary build bot is broken it is the commiter's responsibility to get the build working or find someone to help them.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.