Commit policy for lp:fluidity

The following development policy applies for commits to lp:fluidity:

* Large development projects should be preceded by discussion on the fluidity mailing list, IRC channel and/or use of Launchpad's Blueprints service on the Fluidity project.

* Smaller feature additions do not require such discussion assuming they will not adversely affect other people's work. If you are unsure ask the fluidity@imperial.ac.uk mailing list, on IRC (#amcg) or submit a Blueprint.

* Development should only take place on branches. If you wish to collaborate with development, branches should be registered under the Fluidity project, rather than an individual branch.

* Merges of feature branches considered ready for development into lp:fluidity must be requested via Launchpad's merge request feature and need to be approved. If possible, a reviewer or group of reviewers should be chosen, but any developer is welcome to participate in the merge request discussion. It is your responsibility to ensure your code is reviewed, but please be aware reviewers are also busy and a large code change may take some time to review.

* Branches may be merged into lp:fluidity only when they are up to date with lp:fluidity, contain completed development units, and pass all tests up to medium tests. Buildbot queues for branches may be requested to this end.

* Commits to lp:fluidity should only be merges from branches, small fixes following merges, or orthogonal commits, for example to the build process and documentation.

* During periods where the trunk is frozen, only bug fix commits are allowed, no merges or commits introducing features.

* lp:fluidity will be merged regularly into fluidity/4.1 (the current release) and an announcement will be made via the fluidity@imperial.ac.uk mailing list when this is done. At the same time, the debian package and tarballs will be updated.