Difference between revisions of "Developer Area/Commit Policy"

From Mahara Wiki
Jump to navigation Jump to search
m
(Added revision policy description (described what we currently have))
Line 1: Line 1:
There are '''no committers''' in the project except for a bot which automatically merges code reviewed commits from Gerrit to Gitorious.
+
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.  
  
Mahara Reviewers are individuals who can make decisions about what gets merged into master based on their review of the changes. In other words, they can give +2 or -2 in Gerrit.
+
There are '''no committers''' in the [http://gitorious.org/mahara/mahara main project repository] except for a bot which automatically merges the reviewed commits from Gerrit to the main Mahara repo on [http://gitorious.org/mahara/mahara Gitorious].
  
These people are also part of the "Mahara Core" team on Launchpad.
+
=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 [https://launchpad.net/~mahara-core "Mahara Reviewers"] team on Launchpad.
  
 
=Becoming a reviewer=
 
=Becoming a reviewer=

Revision as of 08:30, 27 June 2011

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 Gitorious.

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.