mirrors/django
mirrors/django
0
0
Fork 0
mirror of https://github.com/django/django.git synced 2024-11-29 22:56:46 +01:00
Code Issues Releases Wiki Activity

Updated contributing docs for some latest practices.

Browse Source
This commit is contained in:
Tim Graham 2018-04-06 13:04:11 -04:00
parent 85d853b2d3
commit 3428be3cf9
3 changed files with 19 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
docs/internals/contributing/committing-code.txt
View File

@ -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:
<https://code.djangoproject.com/wiki/CommitterTips#AutomatingBackports>`_
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
=================

4
docs/internals/contributing/writing-code/submitting-patches.txt
View File

@ -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 <supported-versions-policy>`
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
------------

8
docs/internals/howto-release-django.txt
View File

@ -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.)