From 12a30e92210144ac5e5762d55131dd10740fa463 Mon Sep 17 00:00:00 2001
From: Tim Graham <timograham@gmail.com>
Date: Sun, 15 Sep 2013 14:14:26 -0400
Subject: [PATCH] [1.5.x] Cleaned up 1.5.4/1.4.8 release notes

Backport of 8d29005524 from master
---
 docs/howto/error-reporting.txt |  6 +++++-
 docs/releases/1.4-alpha-1.txt  |  7 ++++---
 docs/releases/1.4-beta-1.txt   |  7 ++++---
 docs/releases/1.4.8.txt        | 21 ++++++++++++++++-----
 docs/releases/1.4.txt          |  9 +++++----
 docs/releases/1.5.4.txt        | 29 ++++++++++++++++++++++++-----
 docs/releases/index.txt        |  2 ++
 7 files changed, 60 insertions(+), 21 deletions(-)

diff --git a/docs/howto/error-reporting.txt b/docs/howto/error-reporting.txt
index 6239972542..588891e07b 100644
--- a/docs/howto/error-reporting.txt
+++ b/docs/howto/error-reporting.txt
@@ -119,6 +119,8 @@ Filtering error reports
 Filtering sensitive information
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
+.. currentmodule:: django.views.decorators.debug
+
 Error reports are really helpful for debugging errors, so it is generally
 useful to record as much relevant information about those errors as possible.
 For example, by default Django records the `full traceback`_ for the
@@ -246,11 +248,13 @@ attribute::
             request.exception_reporter_filter = CustomExceptionReporterFilter()
         ...
 
+.. currentmodule:: django.views.debug
+
 Your custom filter class needs to inherit from
 :class:`django.views.debug.SafeExceptionReporterFilter` and may override the
 following methods:
 
-.. class:: django.views.debug.SafeExceptionReporterFilter
+.. class:: SafeExceptionReporterFilter
 
 .. method:: SafeExceptionReporterFilter.is_active(self, request)
 
diff --git a/docs/releases/1.4-alpha-1.txt b/docs/releases/1.4-alpha-1.txt
index 36b70bab63..94e875c680 100644
--- a/docs/releases/1.4-alpha-1.txt
+++ b/docs/releases/1.4-alpha-1.txt
@@ -337,9 +337,10 @@ docs </ref/contrib/csrf>` for more information.
 Error report filtering
 ~~~~~~~~~~~~~~~~~~~~~~
 
-Two new function decorators, :func:`sensitive_variables` and
-:func:`sensitive_post_parameters`, were added to allow designating the
-local variables and POST parameters which may contain sensitive
+We added two function decorators,
+:func:`~django.views.decorators.debug.sensitive_variables` and
+:func:`~django.views.decorators.debug.sensitive_post_parameters`, to allow
+designating the local variables and POST parameters that may contain sensitive
 information and should be filtered out of error reports.
 
 All POST parameters are now systematically filtered out of error reports for
diff --git a/docs/releases/1.4-beta-1.txt b/docs/releases/1.4-beta-1.txt
index dd5d9ab6be..18d91862ca 100644
--- a/docs/releases/1.4-beta-1.txt
+++ b/docs/releases/1.4-beta-1.txt
@@ -375,9 +375,10 @@ docs </ref/contrib/csrf>` for more information.
 Error report filtering
 ~~~~~~~~~~~~~~~~~~~~~~
 
-Two new function decorators, :func:`sensitive_variables` and
-:func:`sensitive_post_parameters`, were added to allow designating the
-local variables and POST parameters which may contain sensitive
+We added two function decorators,
+:func:`~django.views.decorators.debug.sensitive_variables` and
+:func:`~django.views.decorators.debug.sensitive_post_parameters`, to allow
+designating the local variables and POST parameters that may contain sensitive
 information and should be filtered out of error reports.
 
 All POST parameters are now systematically filtered out of error reports for
diff --git a/docs/releases/1.4.8.txt b/docs/releases/1.4.8.txt
index bec5a4b7dc..08dca4065e 100644
--- a/docs/releases/1.4.8.txt
+++ b/docs/releases/1.4.8.txt
@@ -1,21 +1,32 @@
 ==========================
-Django 1.4.7 release notes
+Django 1.4.8 release notes
 ==========================
 
 *September 14, 2013*
 
-Django 1.4.8 fixes one security issue present in previous Django releases in
+Django 1.4.8 fixes two security issues present in previous Django releases in
 the 1.4 series.
 
 Denial-of-service via password hashers
 --------------------------------------
 
-In previous versions of Django no limit was imposed on the plaintext
-length of a password. This allows a denial-of-service attack through
+In previous versions of Django, no limit was imposed on the plaintext
+length of a password. This allowed a denial-of-service attack through
 submission of bogus but extremely large passwords, tying up server
 resources performing the (expensive, and increasingly expensive with
 the length of the password) calculation of the corresponding hash.
 
 As of 1.4.8, Django's authentication framework imposes a 4096-byte
-limit on passwords, and will fail authentication with any submitted
+limit on passwords and will fail authentication with any submitted
 password of greater length.
+
+Corrected usage of :func:`~django.views.decorators.debug.sensitive_post_parameters` in :mod:`django.contrib.auth`’s admin
+-------------------------------------------------------------------------------------------------------------------------
+
+The decoration of the ``add_view`` and ``user_change_password`` user admin
+views with :func:`~django.views.decorators.debug.sensitive_post_parameters`
+did not include :func:`~django.utils.decorators.method_decorator` (required
+since the views are methods) resulting in the decorator not being properly
+applied. This usage has been fixed and
+:func:`~django.views.decorators.debug.sensitive_post_parameters` will now
+throw an exception if it's improperly used.
diff --git a/docs/releases/1.4.txt b/docs/releases/1.4.txt
index d1094280c9..4ff1ce6d72 100644
--- a/docs/releases/1.4.txt
+++ b/docs/releases/1.4.txt
@@ -507,10 +507,11 @@ docs </ref/contrib/csrf>` for more information.
 Error report filtering
 ~~~~~~~~~~~~~~~~~~~~~~
 
-We added two function decorators, :func:`sensitive_variables` and
-:func:`sensitive_post_parameters`, to allow designating the local variables
-and POST parameters that may contain sensitive information and should be
-filtered out of error reports.
+We added two function decorators,
+:func:`~django.views.decorators.debug.sensitive_variables` and
+:func:`~django.views.decorators.debug.sensitive_post_parameters`, to allow
+designating the local variables and POST parameters that may contain sensitive
+information and should be filtered out of error reports.
 
 All POST parameters are now systematically filtered out of error reports for
 certain views (``login``, ``password_reset_confirm``, ``password_change`` and
diff --git a/docs/releases/1.5.4.txt b/docs/releases/1.5.4.txt
index 00c56bc5e5..68deeb5de0 100644
--- a/docs/releases/1.5.4.txt
+++ b/docs/releases/1.5.4.txt
@@ -1,21 +1,40 @@
 ==========================
-Django 1.5.3 release notes
+Django 1.5.4 release notes
 ==========================
 
 *September 14, 2013*
 
 This is Django 1.5.4, the fourth release in the Django 1.5 series. It addresses
-one security issue.
+two security issues and one bug.
 
 Denial-of-service via password hashers
 --------------------------------------
 
-In previous versions of Django no limit was imposed on the plaintext
-length of a password. This allows a denial-of-service attack through
+In previous versions of Django, no limit was imposed on the plaintext
+length of a password. This allowed a denial-of-service attack through
 submission of bogus but extremely large passwords, tying up server
 resources performing the (expensive, and increasingly expensive with
 the length of the password) calculation of the corresponding hash.
 
-As of 1.5.3, Django's authentication framework imposes a 4096-byte
+As of 1.5.4, Django's authentication framework imposes a 4096-byte
 limit on passwords, and will fail authentication with any submitted
 password of greater length.
+
+Corrected usage of :func:`~django.views.decorators.debug.sensitive_post_parameters` in :mod:`django.contrib.auth`’s admin
+-------------------------------------------------------------------------------------------------------------------------
+
+The decoration of the ``add_view`` and ``user_change_password`` user admin
+views with :func:`~django.views.decorators.debug.sensitive_post_parameters`
+did not include :func:`~django.utils.decorators.method_decorator` (required
+since the views are methods) resulting in the decorator not being properly
+applied. This usage has been fixed and
+:func:`~django.views.decorators.debug.sensitive_post_parameters` will now
+throw an exception if it's improperly used.
+
+Bugfixes
+========
+
+* Fixed a bug that prevented a ``QuerySet`` that uses
+  :meth:`~django.db.models.query.QuerySet.prefetch_related` from being pickled
+  and unpickled more than once (the second pickling attempt raised an
+  exception) (#21102).
diff --git a/docs/releases/index.txt b/docs/releases/index.txt
index f3f741a581..73838afc80 100644
--- a/docs/releases/index.txt
+++ b/docs/releases/index.txt
@@ -22,6 +22,7 @@ Final releases
 .. toctree::
    :maxdepth: 1
 
+   1.5.4
    1.5.3
    1.5.2
    1.5.1
@@ -32,6 +33,7 @@ Final releases
 .. toctree::
    :maxdepth: 1
 
+   1.4.8
    1.4.7
    1.4.6
    1.4.5