Developer Area/Commit Policy

All proposed changes to any branch of the Mahara project go through the compulsory revision process that requires approval of the change by other project members.

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.

A change needs to be both revised and verified before being merged into the codebase.

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

Mahara Reviewers are individuals who can make decisions about what gets merged into the code base based on their review of the changes. They can give +2 or -2 in revision and mark the change as verified. These people are part of the "Mahara Reviewers" team on Launchpad. While Gerrit also keeps a list, the one on Launchpad is the authoritative one as reviewers can leave if they no longer wish to have that responsibility.

Becoming a reviewer

Membership in the 'Mahara Reviewers' group is granted to developers during a Developers Meeting.

Prior to the meeting, the prospective reviewer should create a wiki page listing their contributions, i.e. code contributions and code review 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. Only other Mahara Reviewers are allowed to vote, and a simple majority will decide. Prior to the meeting, the meeting chair or the Mahara project lead will get in touch with all current Mahara Reviewers via the email address on file to let them know about the application. Reviewers can send their vote via email if they can't attend the meeting.

Reviewer access expires after a year, but can be self-renewed before expiry.

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.