647
edits
Changes
Jump to navigation
Jump to search
Line 51:
Line 51: − − == 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^
Development Team/Code Review (view source)
Revision as of 03:44, 7 August 2009
, 03:44, 7 August 2009→Patch guidelines
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.
== Reviewer guidelines ==
== Reviewer guidelines ==