Jump to content

How we handle patches (mmoved): Difference between revisions

How we handle patches (mmoved) (view source)

Revision as of 00:35, 22 March 2011

999 bytes added ,  13 years ago
no edit summary
imported>Jesstess
No edit summary
imported>Jesstess
No edit summary
Line 3:
== As a patch submitter ==
 
=== Before creating a patch series: ===
* File a bug on https://openhatch.org/bugs/ with a link to your code (for example, a git repository somewhere on the Internet, or with patch files as attachments in bug itself.)
 
** If you opt for using git (which we recommend), please read https://github.com/diaspora/diaspora/wiki/Git-Workflow first
# Add unit tests with your functionality changes or additions.
** If you generate patches and attach them, please do a few local commits and create the patch series with "git format-patch". (Read about [[How to generate patches with git format-patch]])▼
*# MakeUse suredocstrings yourand patchcomments iswhere of good qualityappropriate. WriteSpell-check unityour tests,additions. useTry [http://pypi.python.org/pypi/PyChecker/0.8.12to PyChecker] andapply [http://pypi.python.org/pypi/pep8 pep8] tools; use comments and docstrings to explain things when necessarystandards.
# Test your changes on a local instance of the website. Prove to yourself that your changes address the issue they are supposed to address.
* Join IRC and ping someone with deployment access (e.g., ''paulproteus'') until it gets reviewed
# Run the test suite, and make sure your unit tests pass and all tests that passed before your changes still pass.
* If it passes review, it should get deployed immediately.
# Use a tool like [http://pypi.python.org/pypi/PyChecker/0.8.12 PyChecker] to check for bugs.
 
=== While creating a patch series: ===
 
# Before creating the patch, update the master branch of your local repository checkout, and make sure your commits apply cleanly on top of master. In git, you can achieve this by developing on a branch and rebasing your branch commits on top of master.
▲**# IfGenerate youthe generatepatch patchesset andfor attachyour them,changes. pleaseOur dopreferred apatch fewsubmission localform commitsis and create thea patch series generated with "git format-patch". (Read about [[How to generate patches with git format-patch]]).
 
=== Submitting your patch series for review: ===
 
# Attach your patches to the issue ticket at https://openhatch.org/bugs.
# Change the issue status to "in-review".
# Join IRC and say that you have an issue ready for review.
 
If the reviewer says it's ready to go, your patch set will get deployed in short order. If the reviewer has feedback he/she wants addressed, make the necessary revisions and start back at the "Before creating a patch series" section.
 
== As a patch reviewer ==
 
# Review the patch series for correctness and cleanliness.
* Ping the author on IRC (or something) to see if she's/he's uploaded the most recent version.
# If you are satisfied with the patch set:
*## AskIf the author roughlyhasn't thisalready questiondone this: tell the author "Please email devel@lists.openhatch.org saying that you're okay with your work being under AGPLv3the Affero GPL, version 3. If you're willing, it'd beis nicepreferable ifthat you say 'the Affero GPL, version 3 or later, at your option'."
## Have someone with deployment access deploy the changes and monitor the deployment.
# If you have revisions you'd like to see made, change the issue status to "in-progress", re-assign the issue to the patch submitter if it isn't already, and leave your review feedback on the ticket.
Anonymous user
Retrieved from "https://wiki.openhatch.org/wiki/Special:MobileDiff/4433"
Cookies help us deliver our services. By using our services, you agree to our use of cookies.
More information