Development Process

Manasource is a bazaar-style project which is open to input from users and invites everyone to contribute code. But we still need a bit of red tape to keep the development organized. This article describes how a change gets into the official codebase.

Using github.com

This process is the recommended process. Depending on how big and important the change, not all steps are mandatory.

step mandatory where who what
0 only for large and complex new features http://doc.manasource.org anyone creates a RFC article describing a new feature an link it on Requests for Comments
1 only for non-trivial changes or changes you can't do yourself http://bugs.manasource.org anyone creates a bugtracker issue which points out a bug or proposes a new feature
2 only for non-trivial changes or changes you can't do yourself http://bugs.manasource.org all Manasource developers discuss whether the issue needs to be resolved
3 only for non-trivial changes or changes you can't do yourself http://bugs.manasource.org implementing developer assigns the issue to himself / herself
4 always http://github.com (personal fork) implementing developer creates a new branch for solving the issue
5 always http://github.com (personal fork) implementing developer commits his/her solution to the branch
6 always http://github.com/mana implementing developer opens a pull request for his/her branch
7 when there is a bugtracker issue http://bugs.manasource.org implementing developer creates a comment mentioning the pull request
8 when the solution is non-trivial http://github.com/mana all Manasource developers discuss whether the solution is acceptable
9 always http://github.com/mana any Manasource developer expresses his/her agreement with the solution
10 always http://github.com/mana implementing developer merges the pull request
11 when there is a bugtracker issue http://bugs.manasource.org implementing developer closes the bugtracker ticket with a comment mentioning the commit hash
12 when necessary http://doc.manasource.org implementing developer documents the change on the wiki

Using only the bugtracker

This alternative process is for casual contributors who don't want to create a github account. It should be used for small contributions only.

step where who what
0 http://bugs.manasource.org anyone creates a bugtracker issue which points out a bug or proposes a new feature
1 http://bugs.manasource.org all Manasource developers discuss whether the issue needs to be resolved
2 http://bugs.manasource.org implementing developer uploads a patch with the proposed solution to the issue
3 http://bugs.manasource.org all Manasource developers discuss whether the solution is acceptable
4 http://bugs.manasource.org any Manasource developer expresses his/her agreement with the solution 1)
5 http://github.com/mana the developer who agreed with the patch pushes the patch to the main repository
6 http://bugs.manasource.org the developer who agreed with the patch closes the issue mentioning the commit hash
1) Please excuse that patches in bugtracker issues are easily overlooked. Feel free to ask for a review (or reason for not reviewing) on IRC when your patch is ignored for too long.
development_process.txt · Last modified: 2011/09/12 19:32 by Philipp Sehmisch
 
Except where otherwise noted, content on this wiki is licensed under the following license: GNU Free Documentation License 1.3
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki