Difference between revisions of "Developer Area/Commit Policy"
From Mahara Wiki
< Developer Area
Brettwilkins (talk | contribs) (Created page with "Those with commit access to Mahara should follow this simple policy: # '''small fixes'''<nowiki>: go ahead and push them to </nowiki>'''master''' (make sure you "git commit -s" …") |
|||
| Line 1: | Line 1: | ||
Those with commit access to Mahara should follow this simple policy: | Those with commit access to Mahara should follow this simple policy: | ||
| − | # '''small fixes''' | + | # '''small fixes''': go ahead and push them to '''master''' (make sure you "git commit -s" of course) |
| − | # '''larger changes''' or commits to a '''stable branch''' | + | # '''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 :) | # 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.) | # '''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.) | ||
| Line 8: | Line 8: | ||
<div id="section_1"> | <div id="section_1"> | ||
| − | === Stable branches === | + | ===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. | 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> | </div> | ||
Revision as of 15:12, 11 May 2011
Those with commit access to Mahara should follow this simple policy:
- small fixes: go ahead and push them to master (make sure you "git commit -s" of course)
- 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.)
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.