Actions

Difference between revisions of "Developer Area/Commit Policy"

From Mahara Wiki

< Developer Area

Revision as of 18:46, 25 May 2011

Those with commit access to Mahara should follow this simple policy:

  1. small fixes: go ahead and push them to master (make sure you "git commit -s" of course)
  2. 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.
  3. if you're not sure, just ask. we'll be happy to review a 1-line patch quickly if you're not entirely sure :)
  4. 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.)

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.