diff --git a/docs/internals/contributing/committing-code.txt b/docs/internals/contributing/committing-code.txt index a7657a8433..cc1d29c521 100644 --- a/docs/internals/contributing/committing-code.txt +++ b/docs/internals/contributing/committing-code.txt @@ -59,13 +59,9 @@ Once you're ready: $ # Delete the pull request branch. $ git branch -d pr/xxxx -For changes on your own branches, force push to your fork after rebasing on -master but before merging and pushing to upstream. This allows the commit -hashes on master and your branch to match which automatically closes the pull -request. Since you can't push to other contributors' branches, comment on the -pull request "Merged in XXXXXXX" (replacing with the commit hash) after you -merge it. Trac checks for this message format to indicate on the ticket page -whether or not a pull request is merged. +Force push to the branch after rebasing on master but before merging and +pushing to upstream. This allows the commit hashes on master and the branch to +match which automatically closes the pull request. If a pull request doesn't need to be merged as multiple commits, you can use GitHub's "Squash and merge" button on the website. Edit the commit message as @@ -162,10 +158,6 @@ Django's Git repository: 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 #xxxxx." For example: - "[1.4.x] Fixed #123 -- Added whizbang feature." - For the curious, we're using a `Trac plugin`_ for this. .. note:: @@ -202,6 +194,14 @@ Django's Git repository: `_ to automate this. + If the commit fixes a regression, include this in the commit message: + + .. code-block:: none + + Regression in 6ecccad711b52f9273b1acb07a57d3f806e93928. + + (use the commit hash where the regression was introduced). + Reverting commits ================= diff --git a/docs/internals/contributing/writing-code/submitting-patches.txt b/docs/internals/contributing/writing-code/submitting-patches.txt index 15dd431229..5bfff59b52 100644 --- a/docs/internals/contributing/writing-code/submitting-patches.txt +++ b/docs/internals/contributing/writing-code/submitting-patches.txt @@ -273,6 +273,10 @@ Bugs * Is there a proper regression test (the test should fail before the fix is applied)? +* If it's a bug that :ref:`qualifies for a backport ` + to the stable version of Django, is there a release note in + ``docs/releases/A.B.C.txt``? Bug fixes that will be applied only to the + master branch don't need a release note. New Features ------------ diff --git a/docs/internals/howto-release-django.txt b/docs/internals/howto-release-django.txt index 495b7217b5..f14b8663cf 100644 --- a/docs/internals/howto-release-django.txt +++ b/docs/internals/howto-release-django.txt @@ -78,8 +78,8 @@ You'll need a few things before getting started: * If this is a security release, access to the pre-notification distribution list. -If this is your first release, you'll need to coordinate with James and/or -Jacob to get all these things lined up. +If this is your first release, you'll need to coordinate with another releaser +to get all these things lined up. Pre-release tasks ================= @@ -164,14 +164,14 @@ OK, this is the fun part, where we actually push out a release! $ git pull #. If this is a security release, merge the appropriate patches from - ``django-private``. Rebase these patches as necessary to make each one a + ``django-security``. Rebase these patches as necessary to make each one a simple commit on the release branch rather than a merge commit. To ensure this, merge them with the ``--ff-only`` flag; for example:: $ git checkout stable/1.5.x $ git merge --ff-only security/1.5.x - (This assumes ``security/1.5.x`` is a branch in the ``django-private`` repo + (This assumes ``security/1.5.x`` is a branch in the ``django-security`` repo containing the necessary security patches for the next release in the 1.5 series.)