Revision as of 17:58, 25 May 2011

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.

These people are also part of the "Mahara Core" 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.

@@ Line 1: / Line 1: @@
-Those with commit access to Mahara should follow this simple policy:
+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.
-# '''small fixes''': go ahead and push them to '''master''' (make sure you "git commit -s" of course)
+These people are also part of the "Mahara Core" team on Launchpad.
-# '''larger changes''' or commits to a '''stable branch''': have them reviewed by a core developer. Add a second "Signed-off-by: Reviewer Name " once it has been approved.
-# if you're not sure, just ask. we'll be happy to review a 1-line patch quickly if you're not entirely sure :)
-# '''security''' fixes: '''do NOT commit'''. Instead file a hidden security bug on Launchpad and attach the patch there. (The reason is obvious: if you commit a security fix, it becomes public and people can start attacking sites.)
-<div id="section_1">
+=Becoming a reviewer=
-===Stable branches===
+Membership in this Gerrit group is granted to developers during a [[Developer Area/Developer Meetings|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.<br /><br /> 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.
-</div>

Difference between revisions of "Developer Area/Commit Policy"

From Mahara Wiki

< Developer Area

Revision as of 17:58, 25 May 2011

Becoming a reviewer

Stable branches