IN PROGRESS

Policies for code development:

Absolutely no power plants

1. Big improvements to the code base involving large number of files and
   source code are discouraged.
2. It keeps people in a loop, and use branches.
3. No Name attribution in the source code.

What is the release process?

SVN Setup Policies:

http://svn.collab.net/repos/svn/trunk/doc/user/svn-best-practices.html

The Branch-When-Needed system

• Users commit their day-to-day work on /trunk.
• Rule #1: /trunk must compile and pass regression tests at all times.
• Rule #2: a single commit (changeset) must not be so large so as to discourage peer-review.
• Rule #3: if rules #1 and #2 come into conflict (i.e. it's impossible to make a series of small commits without disrupting the trunk), then the user should create a branch and commit a series of smaller changesets there. This allows peer-review without disrupting the stability of /trunk.

Pros: /trunk is guaranteed to be stable at all times. The hassle of branching/merging is somewhat rare.

Cons: Adds a bit of burden to users' daily work: they must compile and test before every commit.

Who Creates a new Branch?

Branch and Version Naming Policies:

Log Message Format and Using JIRA Issues with the SVN commit: