Skip to content

FAQ: Commit policy for master

Jump to bottom
Tim Greaves edited this page May 30, 2014 · 2 revisions

The following development policy applies for commits to Fluidity master:

  • Large development projects should be preceded by discussion on the fluidity mailing list, IRC channel and/or developer meetings.

  • 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 attend a developer meeting in person.

  • Development should only take place on branches.

  • Merges of feature branches considered ready for development into master must be requested via a merge request 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 master only when they are up to date with master, contain completed development units, and pass all tests up to medium tests. Buildbot queues for branches may be requested to this end.

  • Commits to master 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.

  • Releases will be periodically created from master, and an announcement will be made via the fluidity@imperial.ac.uk mailing list when this is done. At the same time, the distribution package sets and tarballs will be updated.

Clone this wiki locally