647
edits
Changes
Jump to navigation
Jump to search
Line 10:
Line 10: − + + + Line 18:
Line 20: − + Line 36:
Line 38: − + Line 46:
Line 48: − +
Development Team/Code Review (view source)
Revision as of 03:24, 7 August 2009
, 03:24, 7 August 2009no edit summary
The process is composed by the following phases, explained below: preliminary discussion, proposal, discussion and acceptance.
The process is composed by the following phases, explained below: preliminary discussion, proposal, discussion and acceptance.
= Preliminary discussion =
= Phases =
== Preliminary discussion ==
Except when the patch will be trivial, it's a good idea to notify the maintainers that you are going to work on this issue and discuss possible approaches with them. This avoids duplicated work and will give you an idea of what is considered a good idea by the maintainers before you commit substantial work in the patch itself.
Except when the patch will be trivial, it's a good idea to notify the maintainers that you are going to work on this issue and discuss possible approaches with them. This avoids duplicated work and will give you an idea of what is considered a good idea by the maintainers before you commit substantial work in the patch itself.
Plan your work together with the maintainer in such a way that code will be submitted in chunks of reasonable size, a good rule of thumb is in patches of below 2000 lines.
Plan your work together with the maintainer in such a way that code will be submitted in chunks of reasonable size, a good rule of thumb is in patches of below 2000 lines.
= Proposal =
== Proposal ==
* Create your patch using the 'git format-patch' command.
* Create your patch using the 'git format-patch' command.
* note possible dependencies e.g. the patch is for sugar but depend on the current HEAD of sugar-toolkit which went in 5 seconds ago
* note possible dependencies e.g. the patch is for sugar but depend on the current HEAD of sugar-toolkit which went in 5 seconds ago
= Discussion =
== Discussion ==
Maintainers and peers of the Sugar modules periodically check the review queue in Trac. If a few day passes without comment since the patch was submitted, please ping the maintainer in IRC or in the mailing list. At times maintainers are very busy and will appreciate the ping, even if repeated.
Maintainers and peers of the Sugar modules periodically check the review queue in Trac. If a few day passes without comment since the patch was submitted, please ping the maintainer in IRC or in the mailing list. At times maintainers are very busy and will appreciate the ping, even if repeated.
Once you have answered the questions and/or attached a new patch, set the 'r-' keyword back to 'r?'.
Once you have answered the questions and/or attached a new patch, set the 'r-' keyword back to 'r?'.
= Acceptance =
== Acceptance ==
Once your patch has received a 'r+', the reviewer will push your code to the repository. From now on your code is part of the Sugar code base and the community will maintain it for you.
Once your patch has received a 'r+', the reviewer will push your code to the repository. From now on your code is part of the Sugar code base and the community will maintain it for you.