diff options
Diffstat (limited to 'docs/internals/contributing/committing-code.txt')
| -rw-r--r-- | docs/internals/contributing/committing-code.txt | 124 |
1 files changed, 62 insertions, 62 deletions
diff --git a/docs/internals/contributing/committing-code.txt b/docs/internals/contributing/committing-code.txt index ffdff60717..e33269be4d 100644 --- a/docs/internals/contributing/committing-code.txt +++ b/docs/internals/contributing/committing-code.txt @@ -38,58 +38,58 @@ Committing guidelines Please follow these guidelines when committing code to Django's Subversion repository: - * For any medium-to-big changes, where "medium-to-big" is according to - your judgment, please bring things up on the `django-developers`_ - mailing list before making the change. +* For any medium-to-big changes, where "medium-to-big" is according to + your judgment, please bring things up on the `django-developers`_ + mailing list before making the change. - If you bring something up on `django-developers`_ and nobody responds, - please don't take that to mean your idea is great and should be - implemented immediately because nobody contested it. Django's lead - developers don't have a lot of time to read mailing-list discussions - immediately, so you may have to wait a couple of days before getting a - response. + If you bring something up on `django-developers`_ and nobody responds, + please don't take that to mean your idea is great and should be + implemented immediately because nobody contested it. Django's lead + developers don't have a lot of time to read mailing-list discussions + immediately, so you may have to wait a couple of days before getting a + response. - * Write detailed commit messages in the past tense, not present tense. +* Write detailed commit messages in the past tense, not present tense. - * Good: "Fixed Unicode bug in RSS API." - * Bad: "Fixes Unicode bug in RSS API." - * Bad: "Fixing Unicode bug in RSS API." + * Good: "Fixed Unicode bug in RSS API." + * Bad: "Fixes Unicode bug in RSS API." + * Bad: "Fixing Unicode bug in RSS API." - * For commits to a branch, prefix the commit message with the branch name. - For example: "magic-removal: Added support for mind reading." +* For commits to a branch, prefix the commit message with the branch name. + For example: "magic-removal: Added support for mind reading." - * Limit commits to the most granular change that makes sense. This means, - use frequent small commits rather than infrequent large commits. For - example, if implementing feature X requires a small change to library Y, - first commit the change to library Y, then commit feature X in a - separate commit. This goes a *long way* in helping all core Django - developers follow your changes. +* Limit commits to the most granular change that makes sense. This means, + use frequent small commits rather than infrequent large commits. For + example, if implementing feature X requires a small change to library Y, + first commit the change to library Y, then commit feature X in a + separate commit. This goes a *long way* in helping all core Django + developers follow your changes. - * Separate bug fixes from feature changes. +* Separate bug fixes from feature changes. - Bug fixes need to be added to the current bugfix branch as well as the - current trunk. + Bug fixes need to be added to the current bugfix branch as well as the + current trunk. - * If your commit closes a ticket in the Django `ticket tracker`_, begin - your commit message with the text "Fixed #abc", where "abc" is the - number of the ticket your commit fixes. Example: "Fixed #123 -- Added - support for foo". We've rigged Subversion and Trac so that any commit - message in that format will automatically close the referenced ticket - and post a comment to it with the full commit message. +* If your commit closes a ticket in the Django `ticket tracker`_, begin + your commit message with the text "Fixed #abc", where "abc" is the + number of the ticket your commit fixes. Example: "Fixed #123 -- Added + support for foo". We've rigged Subversion and Trac so that any commit + message in that format will automatically close the referenced ticket + and post a comment to it with the full commit message. - If your commit closes a ticket and is in a branch, use the branch name - first, then the "Fixed #abc." For example: - "magic-removal: Fixed #123 -- Added whizbang feature." + If your commit closes a ticket and is in a branch, use the branch name + first, then the "Fixed #abc." For example: + "magic-removal: Fixed #123 -- Added whizbang feature." - For the curious: we're using a `Trac post-commit hook`_ for this. + For the curious: we're using a `Trac post-commit hook`_ for this. - .. _Trac post-commit hook: http://trac.edgewall.org/browser/trunk/contrib/trac-post-commit-hook + .. _Trac post-commit hook: http://trac.edgewall.org/browser/trunk/contrib/trac-post-commit-hook - * If your commit references a ticket in the Django `ticket tracker`_ but - does *not* close the ticket, include the phrase "Refs #abc", where "abc" - is the number of the ticket your commit references. We've rigged - Subversion and Trac so that any commit message in that format will - automatically post a comment to the appropriate ticket. +* If your commit references a ticket in the Django `ticket tracker`_ but + does *not* close the ticket, include the phrase "Refs #abc", where "abc" + is the number of the ticket your commit references. We've rigged + Subversion and Trac so that any commit message in that format will + automatically post a comment to the appropriate ticket. Reverting commits ----------------- @@ -97,35 +97,35 @@ Reverting commits Nobody's perfect; mistakes will be committed. When a mistaken commit is discovered, please follow these guidelines: - * Try very hard to ensure that mistakes don't happen. Just because we - have a reversion policy doesn't relax your responsibility to aim for - the highest quality possible. Really: double-check your work before - you commit it in the first place! +* Try very hard to ensure that mistakes don't happen. Just because we + have a reversion policy doesn't relax your responsibility to aim for + the highest quality possible. Really: double-check your work before + you commit it in the first place! - * If possible, have the original author revert his/her own commit. +* If possible, have the original author revert his/her own commit. - * Don't revert another author's changes without permission from the - original author. +* Don't revert another author's changes without permission from the + original author. - * If the original author can't be reached (within a reasonable amount - of time -- a day or so) and the problem is severe -- crashing bug, - major test failures, etc -- then ask for objections on the - `django-developers`_ mailing list then revert if there are none. +* If the original author can't be reached (within a reasonable amount + of time -- a day or so) and the problem is severe -- crashing bug, + major test failures, etc -- then ask for objections on the + `django-developers`_ mailing list then revert if there are none. - * If the problem is small (a feature commit after feature freeze, - say), wait it out. +* If the problem is small (a feature commit after feature freeze, + say), wait it out. - * If there's a disagreement between the committer and the - reverter-to-be then try to work it out on the `django-developers`_ - mailing list. If an agreement can't be reached then it should - be put to a vote. +* If there's a disagreement between the committer and the + reverter-to-be then try to work it out on the `django-developers`_ + mailing list. If an agreement can't be reached then it should + be put to a vote. - * If the commit introduced a confirmed, disclosed security - vulnerability then the commit may be reverted immediately without - permission from anyone. +* If the commit introduced a confirmed, disclosed security + vulnerability then the commit may be reverted immediately without + permission from anyone. - * The release branch maintainer may back out commits to the release - branch without permission if the commit breaks the release branch. +* The release branch maintainer may back out commits to the release + branch without permission if the commit breaks the release branch. .. _django-developers: http://groups.google.com/group/django-developers .. _ticket tracker: http://code.djangoproject.com/newticket |