Various tweaks and additions to 'how to release Django' document.

1 files changed, 37 insertions, 24 deletions

diff --git a/docs/internals/howto-release-django.txt b/docs/internals/howto-release-django.txt
index 1dc80b553e..fffdc9b869 100644
--- a/docs/internals/howto-release-django.txt
+++ b/docs/internals/howto-release-django.txt
@@ -36,7 +36,7 @@ differences noted. The short version is:
 
 #. Update version numbers and create the release package(s)!
 
-#. Upload the package(s) to the the ``djangoproject.com`` server and creating
+#. Upload the package(s) to the the ``djangoproject.com`` server and create
    some redirects for download/checksum links.
 
 #. Unless this is a pre-release, add the new version(s) to PyPI.
@@ -47,7 +47,7 @@ differences noted. The short version is:
 
 #. Update version numbers post-release.
 
-There's a lot of details, so please read on.
+There are a lot of details, so please read on.
 
 Prerequisites
 =============
@@ -116,7 +116,7 @@ before release:
    __ https://github.com/django/djangoproject.com/commit/772edbc6ac5a2b8e718606b3338f2bcc429fb9b6
 
 #. Write the announcement blog post for the release. You can enter it into
-   the admin at any time and mark it as inactive. Here's a few examples:
+   the admin at any time and mark it as inactive. Here are a few examples:
    `example security release announcement`__, `example regular release
    announcement`__, `example pre-release announcement`__.
 
@@ -135,19 +135,28 @@ Actually rolling the release
 
 OK, this is the fun part, where we actually push out a release!
 
-#. Check Jenkins is green for the version(s) you're putting out. You probably
-   shouldn't issue a release until it's green.
+#. Check `Jenkins`__ is green for the version(s) you're putting out. You
+   probably shouldn't issue a release until it's green.
+
+   __ http://ci.djangoproject.com
+
+#. A release always begins from a release branch, so you should ``git checkout
+   stable/<release>`` (e.g. checkout ``stable/1.5.x`` to issue a release in the
+   1.5 series) and then ``git pull`` to make sure you're up-to-date.
 
-#. A release always begins from a release branch, so you
-   should ``git pull`` to make sure you're up-to-date and then
-   ``git checkout stable/<release>`` (e.g. checkout ``stable/1.5.x`` to issue
-   a release in the 1.5 series.)
 
 #. If this is a security release, merge the appropriate patches from
-   ``django-private``. *FIXME: actual commands here - make sure to --ff-
-   only right?*. Make sure the commit messages explain that the commit
-   is a security fix and that an announcement will follow (`example
-   security commit`__)
+   ``django-private``. 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``, if ``security/1.5.x`` is
+   a branch in the ``django-private`` repo containing the necessary security
+   patches for the next release in the 1.5 series. If git refuses to merge with
+   ``--ff-only``, switch to the security-patch branch and rebase it on the
+   branch you are about to merge it into (``git checkout security/1.5.x; git
+   rebase stable/1.5.x``) and then switch back and do the merge. Make sure the
+   commit message for each security fix explains that the commit is a security
+   fix and that an announcement will follow (`example security commit`__)
 
    __ https://github.com/django/django/commit/3ef4bbf495cc6c061789132e3d50a8231a89406b
 
@@ -166,7 +175,7 @@ OK, this is the fun part, where we actually push out a release!
    classifier in ``setup.py`` to reflect this. Otherwise, make sure the
    classifier is set to ``Development Status :: 5 - Production/Stable``.
 
-#. Tag the release by running ``git tag`` *FIXME actual commands*.
+#. Tag the release by running ``git tag -s`` *FIXME actual commands*.
 
 #. ``git push`` your work.
 
@@ -207,7 +216,7 @@ Now you're ready to actually put the release out there. To do this:
    ``/home/www/djangoproject.com/src/media/pgp``.
 
 #. Test that the release packages install correctly using ``easy_install``
-   and ``pip``. Here's how I do it (which requires `virtualenvwrapper`__):
+   and ``pip``. Here's one method (which requires `virtualenvwrapper`__)::
 
         $ mktmpenv
         $ easy_install https://www.djangoproject.com/download/<version>/tarball/
@@ -217,20 +226,24 @@ Now you're ready to actually put the release out there. To do this:
         $ deactivate
 
    This just tests that the tarballs are available (i.e. redirects are up) and
-   that they install correctly, but it'll catch silly mistakes. *XXX FIXME:
+   that they install correctly, but it'll catch silly mistakes. *FIXME:
    buildout too?*
 
    __ https://pypi.python.org/pypi/virtualenvwrapper
 
-#. Ask a few people on IRC to verify the checksums by visiting the chucksums
+#. Ask a few people on IRC to verify the checksums by visiting the checksums
    file (e.g. https://www.djangoproject.com/m/pgp/Django-1.5b1.checksum.txt)
-   and following the instructions in it.
+   and following the instructions in it. For bonus points, they can also unpack
+   the downloaded release tarball and verify that its contents appear to be
+   correct (proper version numbers, no stray ``.pyc`` or other undesirable
+   files).
 
-#. If this is a security or regular release, register the new package with
-   PyPI by uploading the ``PGK-INFO`` file generated in the release package.
-   This file's *in* the distribution tarball, so you'll need to pull it
-   out. ``tar xzf dist/Django-<version>.tar.gz Django-<version>/PKG-INFO``
-   ought to work.
+#. If this is a security or regular release, register the new package with PyPI
+   by uploading the ``PGK-INFO`` file generated in the release package.  This
+   file's *in* the distribution tarball, so you'll need to pull it out. ``tar
+   xzf dist/Django-<version>.tar.gz Django-<version>/PKG-INFO`` ought to
+   work. *FIXME: Is there any reason to pull this file out manually rather than
+   using "python setup.py register"?*
 
 #. Deploy the template changes you made a while back by running `fab deploy`
    from the ``djangoproject.com`` repo.
@@ -240,7 +253,7 @@ Now you're ready to actually put the release out there. To do this:
    to that page listing the preview package; otherwise, just update
    the "Get the latest official version" section.
 
-#. Make up the blog post announcing the release live.
+#. Make the blog post announcing the release live.
 
 #. Post the release announcement to the django-announce,
    django-developers and django-users mailing lists. This should