647
edits
Changes
Jump to navigation
Jump to search
Line 1:
Line 1: − + Line 7:
Line 7: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 43:
Line 75: − − == Patch submission == − − * If your patch addresses an issue which is not registered in [http://dev.sugarlabs.org the Sugar Labs trac instance], please open a new ticket for it. − * Attach the patch to the ticket − * Add the keyword 'r?' to call the attention of reviewers. − * Add a testcase in a ticket comment. You need to mark it with |TestCase|. This adds better readability and our script that pulls together the test cases for each release is able to find it as well. For example: − |TestCase| − − Click on Browse, Read, Pippy icons in the homepage and make sure all of them starts correctly. − − If your patch is a new feature and reasonably big, you may prefer to submit it for review to the Sugar-devel [http://lists.sugarlabs.org/listinfo/sugar-devel mailing list]. If you do please add the review keyword to the ticket anyway and reference the mailing list thread. − − In order to make it easy for the reviewer please: − − * note which module is effected e.g. sugar, sugar-toolkit... − * 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
Development Team/Code Review (view source)
Revision as of 10:50, 6 August 2009
, 10:50, 6 August 2009→Review Process
<noinclude>{{ GoogleTrans-en | es =show | bg =show | zh-CN =show | zh-TW =show | hr =show | cs =show | da =show | nl =show | fi =show | fr =show | de =show | el =show | hi =show | it =show | ja =show | ko =show | no =show | pl =show | pt =show | ro =show | ru =show | sv =show }}</noinclude>{{TOCright}}
<noinclude>{{ GoogleTrans-en | es =show | bg =show | zh-CN =show | zh-TW =show | hr =show | cs =show | da =show | nl =show | fi =show | fr =show | de =show | el =show | hi =show | it =show | ja =show | ko =show | no =show | pl =show | pt =show | ro =show | ru =show | sv =show }}</noinclude>{{TOCright}}
= Review Process =
= Introduction =
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.
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 and deployers, 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 and deployers, etc.
The process is composed by the following phases, explained below: preliminary discussion, proposal, discussion, rework and acceptance.
= 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.
May be interesting as well to discuss with the broad community about the usefulness of any proposed new feature. This way the maintainers will feel more motivated to commit their own time so that your work gets accepted.
= Proposal =
* Create your patch using the "git format-patch" command.
* If your patch addresses an issue which is not registered in [http://dev.sugarlabs.org the Sugar Labs trac instance], please open a new ticket for it.
* Attach the patch to the ticket
* Add the keyword 'r?' to call the attention of reviewers.
* Add a testcase in a ticket comment. You need to mark it with |TestCase|. This adds better readability and our script that pulls together the test cases for each release is able to find it as well. For example:
|TestCase|
Click on Browse, Read, Pippy icons in the homepage and make sure all of them starts correctly.
If your patch is a new feature and reasonably big, you may prefer to submit it for review to the Sugar-devel [http://lists.sugarlabs.org/listinfo/sugar-devel mailing list]. If you do please add the 'r?' keyword to the ticket anyway and reference the mailing list thread.
In order to make it easy for the reviewer please:
* note which module is effected e.g. sugar, sugar-toolkit...
* 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 =
= Rework =
= Acceptance =
== Process guidelines ==
== Process guidelines ==
git format-patch HEAD^
git format-patch HEAD^
git reset --hard HEAD^
git reset --hard HEAD^
== Reviewer guidelines ==
== Reviewer guidelines ==