Developer Area/Commit Policy

All proposed changes to master branch of the project now go through the compulsory revision process that requires approval of the change by the other developers.

There are no committers in the main project repository except for a bot which automatically merges the reviewed commits from Gerrit to the main Mahara repo on git.mahara.org.

Revision policy

Anybody can submit the change, get feedback from core developers and participate in revision process.

Change needs to be both revised and verified before being merged into master.

Anybody can do revision (add +1 or -1 revision points).

Mahara Reviewers are individuals who can make decisions about what gets merged into master based on their review of the changes. They can give +2 or -2 in revision and mark the change as verified. These people are also part of the "Mahara Reviewers" team on Launchpad.

Becoming a reviewer

Membership in this Gerrit group is granted to developers during a Developers Meeting.

Prior to the meeting, the prospective reviewer should create a wiki page listing his or her contributions, then add a link to it on the meeting agenda.

During the meeting, existing reviewers will reach a consensus to make this person a reviewer.

Reviewer access expire after a year, but can be self-renewed (for another year) before they expire.

Stable branches

We try as much as possible to limit the fixes that go onto the stable branch to important fixes only. Of course that definition is entirely subjective :) But the idea is to limit the number of changes on the stable branches as much as possible to reduce the possibility of introducing bugs and to make it easier to patch all of the different versions we need to support in Ubuntu and Debian.

We aim at making a new major release every 6 months or so. Therefore fixes to master should make it to a release within a reasonable timeframe.