Merge remote-tracking branch 'core/master' into schema-alteration

Conflicts:
	docs/ref/django-admin.txt

docs/internals/contributing/writing-code/working-with-git.txt

@@ -157,7 +157,7 @@ using interactive rebase::
 The HEAD~2 above is shorthand for two latest commits. The above command
 will open an editor showing the two commits, prefixed with the word "pick".
 
-Change the second line to "squash" instead. This will keep the
+Change "pick" on the second line to "squash" instead. This will keep the
 first commit, and squash the second commit into the first one. Save and quit
 the editor. A second editor window should open, so you can reword the
 commit message for the commit now that it includes both your steps.

docs/internals/deprecation.txt

@@ -370,8 +370,11 @@ these changes.
 * Remove the backward compatible shims introduced to rename the attributes
   ``ChangeList.root_query_set`` and ``ChangeList.query_set``.
 
-* ``django.conf.urls.shortcut`` and ``django.views.defaults.shortcut`` will be
-  removed.
+* ``django.views.defaults.shortcut`` will be removed, as part of the
+  goal of removing all ``django.contrib`` references from the core
+  Django codebase. Instead use
+  ``django.contrib.contenttypes.views.shortcut``. ``django.conf.urls.shortcut``
+  will also be removed.
 
 * Support for the Python Imaging Library (PIL) module will be removed, as it
   no longer appears to be actively maintained & does not work on Python 3.
@@ -442,11 +445,5 @@ these changes.
 2.0
 ---
 
-* ``django.views.defaults.shortcut()``. This function has been moved
-  to ``django.contrib.contenttypes.views.shortcut()`` as part of the
-  goal of removing all ``django.contrib`` references from the core
-  Django codebase. The old shortcut will be removed in the 2.0
-  release.
-
 * ``ssi`` and ``url`` template tags will be removed from the ``future`` template
   tag library (used during the 1.3/1.4 deprecation period).

docs/internals/howto-release-django.txt

@@ -83,10 +83,11 @@ A few items need to be taken care of before even beginning the release process.
 This stuff starts about a week before the release; most of it can be done
 any time leading up to the actual release:
 
-#. If this is a security release, send out pre-notification **one week**
-   before the release. We maintain a list of who gets these pre-notification
-   emails at *FIXME WHERE?*. This email should be signed by the key you'll use
-   for the release, and should include patches for each issue being fixed.
+#. If this is a security release, send out pre-notification **one week** before
+   the release. We maintain a list of who gets these pre-notification emails in
+   the private ``django-core`` repository. This email should be signed by the
+   key you'll use for the release, and should include patches for each issue
+   being fixed.
 
 #. As the release approaches, watch Trac to make sure no release blockers
    are left for the upcoming release.

docs/internals/security.txt

@@ -108,8 +108,12 @@ On the day of disclosure, we will take the following steps:
    relevant patches and new releases, and crediting the reporter of
    the issue (if the reporter wishes to be publicly identified).
 
+4. Post a notice to the `django-announce`_ mailing list that links to the blog
+   post.
+
 .. _the Python Package Index: http://pypi.python.org/pypi
 .. _the official Django development blog: https://www.djangoproject.com/weblog/
+.. _django-announce: http://groups.google.com/group/django-announce
 
 If a reported issue is believed to be particularly time-sensitive --
 due to a known exploit in the wild, for example -- the time between
@@ -214,4 +218,4 @@ If you are added to the notification list, security-related emails
 will be sent to you by Django's release manager, and all notification
 emails will be signed with the same key used to sign Django releases;
 that key has the ID ``0x3684C0C08C8B2AE1``, and is available from most
-commonly-used keyservers.
+commonly-used keyservers.