1,770
edits
Changes
Jump to navigation
Jump to search
Line 4:
Line 4: − + Line 45:
Line 45: + + Line 51:
Line 53: + + + + Line 61:
Line 67: − * <code>git config --global alias.send-to-ml-single '!git send-email -s -p --stat'</code> − * <code>git config --global alias.send-to-ml-series '!git send-email --cover-letter --summary --annotate -s -p --stat'</code> − If you agree to publish your changes under the same license as the software you are changing, please add <code>-s</code> to the two aliases above (send-to-ml-single and send-to-ml-series). If you don't agree, don't post the patch! The reason this is mentioned as a separate step instead of adding it to the examples above is so you need to make a conscious decision and can't sue us for copyright infringement.+ + + + + + + Line 75:
Line 85: − + − + Line 83:
Line 93: − + + + Line 91:
Line 103: − +
Development Team/Code Review (view source)
Revision as of 22:51, 2 November 2011
, 22:51, 2 November 2011no edit summary
Because Sugar is an open source project, anyone can contribute to it and thus improve the learning experience of children all around the world.
Because Sugar is an open source project, anyone can contribute to it and thus improve the learning experience of children all around the world.
Once you have fixed a bug or implemented a new feature, you can send it to the current maintainers of Sugar by following the code review process.
Once you have fixed a bug or implemented a new feature, you ''must'' send it to the current maintainers of Sugar by following the code review process.
This process allows the maintainers to feel confident about taking the responsibility of delivering your code to children. This means applying it to the current code base, fixing any bugs that are later discovered in your code or as consequences of it, modifying your code to gain new features, assisting packagers, deployers and translators, etc.
This process allows the maintainers to feel confident about taking the responsibility of delivering your code to children. This means applying it to the current code base, fixing any bugs that are later discovered in your code or as consequences of it, modifying your code to gain new features, assisting packagers, deployers and translators, etc.
* mention your changes in a changelog below the marker line (the one with just <code>---</code> on it). E.g.:
* mention your changes in a changelog below the marker line (the one with just <code>---</code> on it). E.g.:
v1->v2: break up _recurse_dir into smaller functions
v1->v2: break up _recurse_dir into smaller functions
You will first need to set up <code>git send-email</code> so it can send emails through your mail provider. The manual page contains an [http://www.kernel.org/pub/software/scm/git/docs/git-send-email.html#_use_gmail_as_the_smtp_server example for Gmail users]. You can use the [[Service/smtp|sugarlabs.org SMTP server]] if you have a [[Service/shell|shell account]]. Feel free to ask for help with setting up <code>git send-email</code> in [[IRC#irc.freenode.net_channels|#sugar]] or on [[Mailing Lists#Developer Lists|sugar-devel]].
Recommended git user configuration:
Recommended git user configuration:
* <code>git config --global sendemail.confirm always</code>
* <code>git config --global sendemail.confirm always</code>
* <code>git config --global 'url.gitorious@git.sugarlabs.org:.pushInsteadOf' git://git.sugarlabs.org/</code>
* <code>git config --global 'url.gitorious@git.sugarlabs.org:.pushInsteadOf' git://git.sugarlabs.org/</code>
* <code>git config --global alias.send-to-ml-single '!git send-email --stat'</code>
* <code>git config --global alias.send-to-ml-series '!git send-email --cover-letter --summary --annotate --stat'</code>
If you agree to publish your changes under the same license as the software you are changing, please add <code>-s</code> to the two aliases above (send-to-ml-single and send-to-ml-series). If you don't agree, don't post the patch! The reason this is mentioned as a separate step instead of adding it to the examples above is so you need to make a conscious decision and can't sue us for copyright infringement.
Recommended per-repository git configuration, e.g. for sugar-datastore:
Recommended per-repository git configuration, e.g. for sugar-datastore:
* <code>git config --global merge.conflictstyle diff3</code>
* <code>git config --global merge.conflictstyle diff3</code>
* <code>git config format.headers "Mail-Followup-To: <sugar-devel@lists.sugarlabs.org>"</code>
* <code>git config format.headers "Mail-Followup-To: <sugar-devel@lists.sugarlabs.org>"</code>
* <code>git config sendemail.envelopesender sascha-ml-sugar-devel@dev.null</code>
* <code>git config sendemail.envelopesender sascha-ml-sugar-devel@dev.null</code>
Examples (assuming the above configuration, including the aliases):
* <code>git send-to-ml-single HEAD^..HEAD</code>
* after doing the code changes requested during review:
** <code>git commit -a --amend</code>
** <code>git send-to-ml-single --annotate --subject-prefix="PATCH v2 sugar"</code>
*** add the changelog during this step
*** adjust the subject prefix to use the name of the module you're modifying instead of <code>sugar</code>
== Discussion ==
== Discussion ==
Everyone (including you!) is invited to review patches. Not only does this free up time of the maintainers (they can wait until someone else did a first round of review), but also ensures we make the best use of our collective knowledge (no, the maintainers are neither perfect nor omniscient ;) ).
Everyone (including you!) is invited to review patches. Not only does this free up time of the maintainers (they can wait until someone else did a first round of review), but also ensures we make the best use of our collective knowledge (no, the maintainers are neither perfect nor omniscient ;) ).
If a reviewer thinks your patch is good (and revelant) enough to be included in the upstream version of the software, (s)he will grant his or her Reviewed-By: tag (see the [http://www.kernel.org/doc/Documentation/SubmittingPatches Linux patch submission process] for details).
If a reviewer thinks your patch is good (and revelant) enough to be included in the upstream version of the software, (s)he will grant his or her <code>Reviewed-By:</code> tag (see the [http://www.kernel.org/doc/Documentation/SubmittingPatches Linux patch submission process] for details).
Similarly, everyone is encouraged to try out your patch and give their Tested-By: tag if it worked well for them.
Similarly, everyone is encouraged to try out your patch and give their <code>Tested-By:</code> tag if it worked well for them.
After you addressed review comments, you can submit a new version of your patch (see [[#Patch submission|above]] for how to note what you changed). Please make it a reply to your original patch by using the <code>[http://www.kernel.org/pub/software/scm/git/docs/git-format-patch.html#_options --in-reply-to]</code> option to <code>git send-email</code>. E.g.: <code>git send-to-ml-single --in-reply-to=<1290857483.723474@twin.sascha.silbe.org></code>
After you addressed review comments, you can submit a new version of your patch (see [[#Patch submission|above]] for how to note what you changed). Please make it a reply to your original patch by using the <code>[http://www.kernel.org/pub/software/scm/git/docs/git-format-patch.html#_options --in-reply-to]</code> option to <code>git send-email</code>. E.g.: <code>git send-to-ml-single --in-reply-to=<1290857483.723474@twin.sascha.silbe.org></code>
== Acceptance ==
== Acceptance ==
After your patch has been acknowledged by a maintainer, (s)he will push your code to the repository, including any tags (Reviewed-By:, Tested-By:, etc.) your patch got. From now on your code is part of the Sugar code base and the community (which includes you ;) ) will maintain it for you.
After your patch has been acknowledged by a maintainer, (s)he will push your code to the repository, including any tags (<code>Reviewed-By:</code>, <code>Tested-By:</code>, etc.) your patch got. From now on your code is part of the Sugar code base and the community (which includes you ;) ) will maintain it for you.
If you are a developer with commit access, a maintainer may ask you to commit it with the tags above. On the other hand, there may be temporal restrictions that the maintainer may want to mention.
= Dependencies =
= Dependencies =
= Internal process (maintainers only) =
= Internal process (maintainers only) =
You can get a ready-to-push version of the patch (including Reviewed-By: etc.) by downloading it in mbox format from [https://patchwork.sugarlabs.org/project/sugar/list/ Patchwork].
You can get a ready-to-push version of the patch (including <code>Reviewed-By:</code> etc.) by downloading it in mbox format from [https://patchwork.sugarlabs.org/project/sugar/list/ Patchwork].
After pushing a patch, please change its state in [https://patchwork.sugarlabs.org/project/sugar/list/ Patchwork] to Accepted + Archived and mark all previous versions (if any are remaining) as Superseded + Archived. If the patch fixes a ticket in [https://bugs.sugarlabs.org/ our bug tracker] please close it, too.
After pushing a patch, please change its state in [https://patchwork.sugarlabs.org/project/sugar/list/ Patchwork] to Accepted + Archived and mark all previous versions (if any are remaining) as Superseded + Archived. If the patch fixes a ticket in [https://bugs.sugarlabs.org/ our bug tracker] please close it, too.
[[Category:Development Team]]
[[Category:Development Team]]