Development Team/Code Review

Review Process

We are using a mix of email and trac for the review process. In the future we might change to a specialized tool like review board which we are currently investigating.

Process guidelines

Break your projects into small pieces that can be submitted for review independently. Submit for review whenever you think you need a review - you can tell that best. The reviewer will use review+ or r+ whenever the patch is accepted and ready to go into git master.

The workflow should be something like:

• Code a small part
• Submit to review
• Push to master
• Repeat

There will be cases when this will not be possible but we want to try to follow this guidelines.

We could consider that 1500 lines starts to be too much for a diff, although factors like the add/delete ratio or the invasiveness of the changes should be taken in account.

Patch guidelines

Please try to use pylint to verify your patch for things like exceeding 80 columns etc, unused imports and unused variables. Pylint is not a tool you can rely on 100% but it helps to follow some guidelines and to avoid the most stupid errors like typos. Here is a pylintrc you can use: pylintrc

In the sugar packages use 'make distcheck' to make sure all files are included and the POTFILES.in is up to date.

Create a patch

Normally you can get a patch from git with:

git diff

If you already committed part or all of the new code you need to specify the id of the last commit before yours:

git diff 34a4876f93894309f77b00281b5cb1bb72b3a1e4

Or if the commit you want the diff of was the most-recent commit, you can do:

git diff HEAD^

Another alternative that will give you a patch in a file called 0001-My-cool-patch.patch:

git-add new_file1 new_file2
git-commit -a -m 'My cool patch'
git-format-patch HEAD^
git-reset --hard HEAD^

Patch submission

• If your patch addresses an issue which is not registered in 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 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

Reviewer guidelines

• For complex patches you might want to start with an overall design of the patch.
• Make sure the submitter provided a testcase before approving the patch.
• Make sure that API policy rules are respected.
• Keep an eye on readability, we are roughly following Guido's PEP 8
• Change the r? keyword to r- to indicate that the patch needs work.
• Change the r? keyword to r+ if the patch is ok to be pushed.

Push the patch

If you have write access to the sugar repository you can just do it yourself. 

If you don't have write access to the repository commit the patch to your local repository.

git commit

Generate a patch set using git. The following command will create one file per commit in the current directory.

git-format-patch origin

Make sure that the ticket number is referenced in the commit description!

Buildbot

We are running periodic builds of Sugar using Buildbot. If you break the build you are responsible to get it fixed. If you don't, the release team will take care of it, most likely by reverting your patch. More in detail:

• Every change that causes build or check failures should be immediately fixed or reverted.
• Every change that causes check warnings should be fixed or reverted within 24 hours.

You can use the check command in jhbuild to execute the same checks that Buildbot is doing. You can use the jhbuild pylint configuration, to lint the files your patch modifies.

Trac Action Needed field

If there is a trac ticket at dev.laptop.org, consider setting the "Action Needed" field to "package". Consider the d.l.o trac workflow.

Remind the maintainers about patches

If you don't get any response from the maintainers about the patches you submitted in a few days, feel free to remind about them using the Sugar mailing list or IRC channel.