|
|
| Line 51: |
Line 51: |
|
| |
|
| 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. |
|
| |
| == Patch guidelines ==
| |
| Please try to use [http://www.logilab.org/857 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. sugar-jhbuild contains a pylintrc you can use in the <code>scripts/data</code> directory: [http://git.sugarlabs.org/projects/sugar-jhbuild/repos/mainline/blobs/master/scripts/data/pylintrc pylintrc] (follow "raw blob data")
| |
|
| |
| [http://svn.browsershots.org/trunk/devtools/pep8/pep8.py pep8.py] catches more style errors than pylint, so make sure to run that one, too.
| |
|
| |
| 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^
| |
|
| |
|
| == Reviewer guidelines == | | == Reviewer guidelines == |