gis: Merged revisions 7574-7583,7585-7586,7590-7602,7614-7615,7619-7625,7629,7632-7636 via svnmerge from trunk.

git-svn-id: http://code.djangoproject.com/svn/django/branches/gis@7642 bcc190cf-cafb-0310-a4f2-bffc1f526a37

10 files changed, 392 insertions, 57 deletions

diff --git a/docs/authentication.txt b/docs/authentication.txt
index 79eaf673e7..4ec367a8b5 100644
--- a/docs/authentication.txt
+++ b/docs/authentication.txt
@@ -263,14 +263,25 @@ Creating superusers
 -------------------
 
 ``manage.py syncdb`` prompts you to create a superuser the first time you run
-it after adding ``'django.contrib.auth'`` to your ``INSTALLED_APPS``. But if
-you need to create a superuser after that via the command line, you can use the
-``create_superuser.py`` utility. Just run this command::
+it after adding ``'django.contrib.auth'`` to your ``INSTALLED_APPS``. If you need
+to create a superuser at a later date, you can use a command line utility.
+
+**New in Django development version.**::
+
+    manage.py createsuperuser --username=joe --email=joe@example.com
+
+You will be prompted for a password. After you enter one, the user will be
+created immediately. If you leave off the ``--username`` or the ``--email``
+options, it will prompt you for those values.
+
+If you're using an older release of Django, the old way of creating a superuser
+on the command line still works::
 
     python /path/to/django/contrib/auth/create_superuser.py
 
-Make sure to substitute ``/path/to/`` with the path to the Django codebase on
-your filesystem.
+...where ``/path/to`` is the path to the Django codebase on your filesystem. The
+``manage.py`` command is preferred because it figures out the correct path and
+environment for you.
 
 Storing additional information about users
 ------------------------------------------
diff --git a/docs/contributing.txt b/docs/contributing.txt
index 885f5159b9..c5f98bec11 100644
--- a/docs/contributing.txt
+++ b/docs/contributing.txt
@@ -148,15 +148,17 @@ Once you've claimed a ticket, you have a responsibility to work on that ticket
 in a reasonably timely fashion. If you don't have time to work on it, either
 unclaim it or don't claim it in the first place!
 
-Core Django developers go through the list of claimed tickets from time to
+Ticket triagers go through the list of claimed tickets from time to
 time, checking whether any progress has been made. If there's no sign of
-progress on a particular claimed ticket for a week or two after it's been
-claimed, we will unclaim it for you so that it's no longer monopolized and
+progress on a particular claimed ticket for a week or two, a triager may ask
+you to relinquish the ticket claim so that it's no longer monopolized and
 somebody else can claim it.
 
 If you've claimed a ticket and it's taking a long time (days or weeks) to code,
-keep everybody updated by posting comments on the ticket. That way, we'll know
-not to unclaim it. More communication is better than less communication!
+keep everybody updated by posting comments on the ticket. If you don't provide
+regular updates, and you don't respond to a request for a progress report,
+your claim on the ticket may be revoked. As always, more communication is
+better than less communication!
 
 Which tickets should be claimed?
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -177,10 +179,10 @@ Patch style
       English than in code. Indentation is the most common example; it's hard to
       read patches when the only difference in code is that it's indented.
 
-	* When creating patches, always run ``svn diff`` from the top-level
-	  ``trunk`` directory -- i.e., the one that contains ``django``, ``docs``,
-	  ``tests``, ``AUTHORS``, etc. This makes it easy for other people to apply
-	  your patches.
+    * When creating patches, always run ``svn diff`` from the top-level
+      ``trunk`` directory -- i.e., the one that contains ``django``, ``docs``,
+      ``tests``, ``AUTHORS``, etc. This makes it easy for other people to apply
+      your patches.
 
     * Attach patches to a ticket in the `ticket tracker`_, using the "attach file"
       button. Please *don't* put the patch in the ticket description or comment
@@ -234,22 +236,28 @@ Since a picture is worth a thousand words, let's start there:
    :width: 590
    :alt: Django's ticket workflow
 
-We've got two roles here:
+We've got two official roles here:
 
-    * Core developers: people with commit access who make the decisions and
-      write the bulk of the code.
-
-    * Ticket triagers: community members who keep track of tickets, making
-      sure the tickets are always categorized correctly.
+    * Core developers: people with commit access who make the big decisions 
+      and write the bulk of the code.
 
+    * Ticket triagers: trusted community members with a proven history of
+      working with the Django community. As a result of this history, they
+      have been entrusted by the core developers to make some of the smaller
+      decisions about tickets.
+     
 Second, note the five triage stages:
 
-    1. A ticket starts as "Unreviewed", meaning that a triager has yet to
-       examine the ticket and move it along.
+    1. A ticket starts as "Unreviewed", meaning that nobody has examined
+       the ticket.
 
     2. "Design decision needed" means "this concept requires a design
        decision," which should be discussed either in the ticket comments or on
-       django-developers.
+       `django-developers`_. The "Design decision needed" step will generally
+       only be used for feature requests. It can also be used for issues 
+       that *might* be bugs, depending on opinion or interpretation. Obvious
+       bugs (such as crashes, incorrect query results, or non-compliance with a
+       standard) skip this step and move straight to "Accepted".
 
     3. Once a ticket is ruled to be approved for fixing, it's moved into the
        "Accepted" stage. This stage is where all the real work gets done.
@@ -269,7 +277,7 @@ ticket has or needs in order to be "ready for checkin":
 
     "Has patch"
         This means the ticket has an associated patch_. These will be
-        reviewed to see if the patch is "good".
+        reviewed by the triage team to see if the patch is "good".
 
     "Needs documentation"
         This flag is used for tickets with patches that need associated
@@ -292,7 +300,11 @@ A ticket can be resolved in a number of ways:
         Django and the issue is fixed.
 
     "invalid"
-        Used if the ticket is found to be incorrect or a user error.
+        Used if the ticket is found to be incorrect. This means that the
+        issue in the ticket is actually the result of a user error, or
+        describes a problem with something other than Django, or isn't
+        a bug report or feature request at all (for example, some new users
+        submit support queries as tickets).
 
     "wontfix"
         Used when a core developer decides that this request is not
@@ -305,7 +317,8 @@ A ticket can be resolved in a number of ways:
         tickets, we keep all the discussion in one place, which helps everyone.
 
     "worksforme"
-        Used when the triage team is unable to replicate the original bug.
+        Used when the the ticket doesn't contain enough detail to replicate 
+        the original bug.
 
 If you believe that the ticket was closed in error -- because you're
 still having the issue, or it's popped up somewhere else, or the triagers have
@@ -316,6 +329,55 @@ reopen tickets that have been marked as "wontfix" by core developers.
 .. _good patch: `Patch style`_
 .. _patch: `Submitting patches`_
 
+Triage by the general community
+-------------------------------
+
+Although the Core Developers and Ticket Triagers make the big decisions in
+the ticket triage process, there is also a lot that general community 
+members can do to help the triage process. In particular, you can help out by:
+
+    * Closing "Unreviewed" tickets as "invalid", "worksforme", or "duplicate".
+
+    * Promoting "Unreviewed" tickets to "Design Decision Required" if there
+      is a design decision that needs to be made, or "Accepted" if they are
+      an obvious bug.
+
+    * Correcting the "Needs Tests", "Needs documentation", or "Has Patch" flags
+      for tickets where they are incorrectly set.
+ 
+    * Checking that old tickets are still valid. If a ticket hasn't seen
+      any activity in a long time, it's possible that the problem has been
+      fixed, but the ticket hasn't been closed. 
+
+    * Contact the owners of tickets that have been claimed, but have not seen 
+      any recent activity. If the owner doesn't respond after a week or so, 
+      remove the owner's claim on the ticket.
+
+    * Identifying trends and themes in the tickets. If there a lot of bug reports
+      about a particular part of Django, it possibly indicates that we need
+      to consider refactoring that part of the code. If a trend is emerging,
+      you should raise it for discussion (referencing the relevant tickets)
+      on `django-developers`_.
+
+However, we do ask that as a general community member working in the
+ticket database:
+
+    * Please **don't** close tickets as "wontfix". The core developers will 
+      make the final determination of the fate of a ticket, usually after  
+      consultation with the community.
+    
+    * Please **don't** promote tickets to "Ready for checkin" unless they are
+      *trivial* changes - for example, spelling mistakes or
+      broken links in documentation. 
+
+    * Please **don't** reverse a decision that has been made by a core 
+      developer. If you disagree with a discussion that has been made, 
+      please post a message to `django-developers`_.
+
+    * Please be conservative in your actions. If you're unsure if you should
+      be making a change, don't make the change - leave a comment with your 
+      concerns on the ticket, or post a message to `django-developers`_.
+
 Submitting and maintaining translations
 =======================================
 
diff --git a/docs/db-api.txt b/docs/db-api.txt
index a15c45d37b..4e1c2c5791 100644
--- a/docs/db-api.txt
+++ b/docs/db-api.txt
@@ -1373,6 +1373,17 @@ SQL equivalent::
 
     SELECT ... WHERE id IN (1, 3, 4);
 
+You can also use a queryset to dynamically evaluate the list of values
+instead of providing a list of literal values. The queryset must be
+reduced to a list of individual values using the ``values()`` method, 
+and then converted into a query using the ``query`` attribute::
+
+    Entry.objects.filter(blog__in=Blog.objects.filter(name__contains='Cheddar').values('pk').query)
+
+This queryset will be evaluated as subselect statement::
+
+    SELET ... WHERE blog.id IN (SELECT id FROM ... WHERE NAME LIKE '%Cheddar%')
+
 startswith
 ~~~~~~~~~~
 
@@ -2026,6 +2037,37 @@ Each "reverse" operation described in this section has an immediate effect on
 the database. Every addition, creation and deletion is immediately and
 automatically saved to the database.
 
+One-to-one relationships
+------------------------
+
+One-to-one relationships are very similar to Many-to-one relationships.
+If you define a OneToOneField on your model, instances of that model will have 
+access to the related object via a simple attribute of the model.
+
+For example::
+
+    class EntryDetail(models.Model):
+        entry = models.OneToOneField(Entry)
+        details = models.TextField()
+
+    ed = EntryDetail.objects.get(id=2)
+    ed.entry # Returns the related Entry object.
+
+The difference comes in reverse queries. The related model in a One-to-one
+relationship also has access to a ``Manager`` object; however, that ``Manager``
+represents a single object, rather than a collection of objects::
+
+    e = Entry.objects.get(id=2)
+    e.entrydetail # returns the related EntryDetail object
+
+If no object has been assigned to this relationship, Django will raise
+a ``DoesNotExist`` exception.
+
+Instances can be assigned to the reverse relationship in the same way as 
+you would assign the forward relationship::
+    
+    e.entrydetail = ed
+
 Many-to-many relationships
 --------------------------
 
@@ -2053,12 +2095,6 @@ above example, if the ``ManyToManyField`` in ``Entry`` had specified
 ``related_name='entries'``, then each ``Author`` instance would have an
 ``entries`` attribute instead of ``entry_set``.
 
-One-to-one relationships
-------------------------
-
-The semantics of one-to-one relationships will be changing soon, so we don't
-recommend you use them.
-
 How are the backward relationships possible?
 --------------------------------------------
 
diff --git a/docs/django-admin.txt b/docs/django-admin.txt
index e79c105bbd..1d4dbf10be 100644
--- a/docs/django-admin.txt
+++ b/docs/django-admin.txt
@@ -93,6 +93,31 @@ backend. See the `cache documentation`_ for more information.
 
 .. _cache documentation: ../cache/
 
+createsuperuser
+---------------
+
+**New in Django development version**
+
+Creates a superuser account (a user who has all permissions). This is
+useful if you need to create an initial superuser account but did not
+do so during ``syncdb``, or if you need to programmatically generate
+superuser accounts for your site(s).
+
+When run interactively, this command will prompt for a password for
+the new superuser account. When run non-interactively, no password
+will be set, and the superuser account will not be able to log in until
+a password has been manually set for it.
+
+The username and e-mail address for the new account can be supplied by
+using the ``--username`` and ``--email`` arguments on the command
+line. If either of those is not supplied, ``createsuperuser`` will prompt for
+it when running interactively.
+
+This command is only available if Django's `authentication system`_
+(``django.contrib.auth``) is installed.
+
+.. _authentication system: ../authentication/
+
 dbshell
 -------
 
@@ -139,6 +164,22 @@ dumped.
 
 .. _custom manager: ../model-api/#custom-managers
 
+--exclude
+~~~~~~~~~
+
+**New in Django development version**
+
+Exclude a specific application from the applications whose contents is
+output. For example, to specifically exclude the `auth` application from
+the output, you would call::
+
+	django-admin.py dumpdata --exclude=auth
+
+If you want to exclude multiple applications, use multiple ``--exclude``
+directives::
+
+	django-admin.py dumpdata --exclude=auth --exclude=contenttype
+
 --format
 ~~~~~~~~
 
@@ -313,9 +354,9 @@ The ``dumpdata`` command can be used to generate input for ``loaddata``.
 Use ``--verbosity`` to specify the amount of notification and debug information
 that ``django-admin.py`` should print to the console.
 
-	* ``0`` means no input.
-	* ``1`` means normal input (default).
-	* ``2`` means verbose input.
+	* ``0`` means no output.
+	* ``1`` means normal output (default).
+	* ``2`` means verbose output.
 
 Example usage::
 
@@ -556,9 +597,9 @@ data files.
 Use ``--verbosity`` to specify the amount of notification and debug information
 that ``django-admin.py`` should print to the console.
 
-	* ``0`` means no input.
-	* ``1`` means normal input (default).
-	* ``2`` means verbose input.
+	* ``0`` means no output.
+	* ``1`` means normal output (default).
+	* ``2`` means verbose output.
 
 Example usage::
 
@@ -592,9 +633,9 @@ is being executed as an unattended, automated script.
 Use ``--verbosity`` to specify the amount of notification and debug information
 that ``django-admin.py`` should print to the console.
 
-	* ``0`` means no input.
-	* ``1`` means normal input (default).
-	* ``2`` means verbose input.
+	* ``0`` means no output.
+	* ``1`` means normal output (default).
+	* ``2`` means verbose output.
 
 Example usage::
 
@@ -668,9 +709,9 @@ To run on 1.2.3.4:7000 with a ``test`` fixture::
 Use ``--verbosity`` to specify the amount of notification and debug information
 that ``django-admin.py`` should print to the console.
 
-	* ``0`` means no input.
-	* ``1`` means normal input (default).
-	* ``2`` means verbose input.
+	* ``0`` means no output.
+	* ``1`` means normal output (default).
+	* ``2`` means verbose output.
 
 Example usage::
 
diff --git a/docs/faq.txt b/docs/faq.txt
index 56c9536eda..6d12a95cba 100644
--- a/docs/faq.txt
+++ b/docs/faq.txt
@@ -226,15 +226,16 @@ When will you release Django 1.0?
 
 Short answer: When we're comfortable with Django's APIs, have added all
 features that we feel are necessary to earn a "1.0" status, and are ready to
-begin maintaining backwards compatibility. 
+begin maintaining backwards compatibility.
 
-The merging of Django's `magic-removal branch`_ went a long way toward Django
-1.0.
+The merging of Django's `Queryset Refactor branch`_ went a long way toward Django
+1.0. Merging the `Newforms Admin branch` will be another important step.
 
 Of course, you should note that `quite a few production sites`_ use Django in
 its current status. Don't let the lack of a 1.0 turn you off.
 
-.. _magic-removal branch: http://code.djangoproject.com/wiki/RemovingTheMagic
+.. _Queryset Refactor branch: http://code.djangoproject.com/wiki/QuerysetRefactorBranch
+.. _Newforms Admin branch: http://code.djangoproject.com/wiki/NewformsAdminBranch
 .. _quite a few production sites: http://code.djangoproject.com/wiki/DjangoPoweredSites
 
 How can I download the Django documentation to read it offline?
@@ -259,7 +260,9 @@ Where can I find Django developers for hire?
 Consult our `developers for hire page`_ for a list of Django developers who
 would be happy to help you.
 
-You might also be interested in posting a job to http://www.gypsyjobs.com/ .
+You might also be interested in posting a job to http://djangogigs.com/ .
+If you want to find Django-capable people in your local area, try
+http://djangopeople.net/ .
 
 .. _developers for hire page: http://code.djangoproject.com/wiki/DevelopersForHire
 
@@ -643,6 +646,81 @@ You can also use the Python API. See `creating users`_ for full info.
 
 .. _creating users: ../authentication/#creating-users
 
+Getting help
+============
+
+How do I do X? Why doesn't Y work? Where can I go to get help?
+--------------------------------------------------------------
+
+If this FAQ doesn't contain an answer to your question, you might want to
+try the `django-users mailing list`_. Feel free to ask any question related
+to installing, using, or debugging Django.
+
+If you prefer IRC, the `#django IRC channel`_ on the Freenode IRC network is an
+active community of helpful individuals who may be able to solve your problem.
+
+.. _`django-users mailing list`: http://groups.google.com/group/django-users
+.. _`#django IRC channel`: irc://irc.freenode.net/django
+
+Why hasn't my message appeared on django-users?
+-----------------------------------------------
+
+django-users_ has a lot of subscribers. This is good for the community, as
+it means many people are available to contribute answers to questions.
+Unfortunately, it also means that django-users_ is an attractive target for
+spammers.
+
+In order to combat the spam problem, when you join the django-users_ mailing
+list, we manually moderate the first message you send to the list. This means
+that spammers get caught, but it also means that your first question to the
+list might take a little longer to get answered. We apologize for any
+inconvenience that this policy may cause.
+
+.. _django-users: http://groups.google.com/group/django-users
+
+Nobody on django-users answered my question! What should I do?
+--------------------------------------------------------------
+
+Try making your question more specific, or provide a better example of your
+problem.
+
+As with most open-source mailing lists, the folks on django-users_ are
+volunteers. If nobody has answered your question, it may be because nobody
+knows the answer, it may be because nobody can understand the question, or it
+may be that everybody that can help is busy. One thing you might try is to ask
+the question on IRC -- visit the `#django IRC channel`_ on the Freenode IRC
+network.
+
+You might notice we have a second mailing list, called django-developers_ --
+but please don't e-mail support questions to this mailing list. This list is
+for discussion of the development of Django itself. Asking a tech support
+question there is considered quite impolite.
+
+.. _django-developers: http://groups.google.com/group/django-developers
+
+I think I've found a bug! What should I do?
+-------------------------------------------
+
+Detailed instructions on how to handle a potential bug can be found in our
+`Guide to contributing to Django`_.
+
+.. _`Guide to contributing to Django`: ../contributing/#reporting-bugs
+
+I think I've found a security problem! What should I do?
+--------------------------------------------------------
+
+If you think you've found a security problem with Django, please send a message
+to security@djangoproject.com. This is a private list only open to long-time,
+highly trusted Django developers, and its archives are not publicly readable.
+
+Due to the sensitive nature of security issues, we ask that if you think you
+have found a security problem, *please* don't send a message to one of the
+public mailing lists. Django has a `policy for handling security issues`_;
+while a defect is outstanding, we would like to minimize any damage that
+could be inflicted through public knowledge of that defect.
+
+.. _`policy for handling security issues`: ../contributing/#reporting-security-issues
+
 Contributing code
 =================
 
@@ -652,7 +730,7 @@ How can I get started contributing code to Django?
 Thanks for asking! We've written an entire document devoted to this question.
 It's titled `Contributing to Django`_.
 
-.. _Contributing to Django: ../contributing/
+.. _`Contributing to Django`: ../contributing/
 
 I submitted a bug fix in the ticket system several weeks ago. Why are you ignoring my patch?
 --------------------------------------------------------------------------------------------
@@ -664,6 +742,11 @@ ignored" and "a ticket has not been attended to yet." Django's ticket system
 contains hundreds of open tickets, of various degrees of impact on end-user
 functionality, and Django's developers have to review and prioritize.
 
+On top of that: the people who work on Django are all volunteers. As a result,
+the amount of time that we have to work on the framework is limited and will
+vary from week to week depending on our spare time. If we're busy, we may not
+be able to spend as much time on Django as we might want.
+
 Besides, if your feature request stands no chance of inclusion in Django, we
 won't ignore it -- we'll just close the ticket. So if your ticket is still
 open, it doesn't mean we're ignoring you; it just means we haven't had time to
diff --git a/docs/outputting_pdf.txt b/docs/outputting_pdf.txt
index bd6ae7a660..dd8a262812 100644
--- a/docs/outputting_pdf.txt
+++ b/docs/outputting_pdf.txt
@@ -143,11 +143,14 @@ Further resources
 
     * PDFlib_ is another PDF-generation library that has Python bindings. To
       use it with Django, just use the same concepts explained in this article.
+    * `Pisa HTML2PDF`_ is yet another PDF-generation library. Pisa ships with
+      an example of how to integrate Pisa with Django.
     * HTMLdoc_ is a command-line script that can convert HTML to PDF. It
       doesn't have a Python interface, but you can escape out to the shell
       using ``system`` or ``popen`` and retrieve the output in Python.
     * `forge_fdf in Python`_ is a library that fills in PDF forms.
 
 .. _PDFlib: http://www.pdflib.org/
+.. _`Pisa HTML2PDF`: http://www.htmltopdf.org/
 .. _HTMLdoc: http://www.htmldoc.org/
 .. _forge_fdf in Python: http://www.accesspdf.com/article.php/20050421092951834
diff --git a/docs/serialization.txt b/docs/serialization.txt
index 8a672d8b8a..2a3e7038da 100644
--- a/docs/serialization.txt
+++ b/docs/serialization.txt
@@ -63,6 +63,41 @@ be serialized.
     doesn't specify all the fields that are required by a model, the deserializer
     will not be able to save deserialized instances.
 
+Inherited Models
+~~~~~~~~~~~~~~~~
+
+If you have a model that is defined using an `abstract base class`_, you don't
+have to do anything special to serialize that model. Just call the serializer
+on the object (or objects) that you want to serialize, and the output will be
+a complete representation of the serialized object.
+
+However, if you have a model that uses `multi-table inheritance`_, you also
+need to serialize all of the base classes for the model. This is because only
+the fields that are locally defined on the model will be serialized. For
+example, consider the following models::
+	
+	class Place(models.Model):
+		name = models.CharField(max_length=50)
+		
+	class Restaurant(Place):
+		serves_hot_dogs = models.BooleanField()
+		
+If you only serialize the Restaurant model::
+
+	data = serializers.serialize('xml', Restaurant.objects.all())
+
+the fields on the serialized output will only contain the `serves_hot_dogs`
+attribute. The `name` attribute of the base class will be ignored.
+
+In order to fully serialize your Restaurant instances, you will need to
+serialize the Place models as well::
+
+	all_objects = list(Restaurant.objects.all()) + list(Place.objects.all())
+	data = serializers.serialize('xml', all_objects)
+
+.. _abstract base class: http://www.djangoproject.com/documentation/model-api/#abstract-base-classes
+.. _multi-table inheritance: http://www.djangoproject.com/documentation/model-api/#multi-table-inheritance
+
 Deserializing data
 ------------------
 
diff --git a/docs/sessions.txt b/docs/sessions.txt
index d8bac5b8d4..da083b7713 100644
--- a/docs/sessions.txt
+++ b/docs/sessions.txt
@@ -80,19 +80,24 @@ attribute, which is a dictionary-like object. You can read it and write to it.
 It implements the following standard dictionary methods:
 
     * ``__getitem__(key)``
+
       Example: ``fav_color = request.session['fav_color']``
 
     * ``__setitem__(key, value)``
+
       Example: ``request.session['fav_color'] = 'blue'``
 
     * ``__delitem__(key)``
+
       Example: ``del request.session['fav_color']``. This raises ``KeyError``
       if the given ``key`` isn't already in the session.
 
     * ``__contains__(key)``
+
       Example: ``'fav_color' in request.session``
 
     * ``get(key, default=None)``
+
       Example: ``fav_color = request.session.get('fav_color', 'red')``
 
     * ``keys()``
@@ -101,23 +106,70 @@ It implements the following standard dictionary methods:
 
     * ``setdefault()`` (**New in Django development version**)
 
-It also has these three methods:
+It also has these methods:
 
     * ``set_test_cookie()``
+
       Sets a test cookie to determine whether the user's browser supports
       cookies. Due to the way cookies work, you won't be able to test this
       until the user's next page request. See "Setting test cookies" below for
       more information.
 
     * ``test_cookie_worked()``
+
       Returns either ``True`` or ``False``, depending on whether the user's
       browser accepted the test cookie. Due to the way cookies work, you'll
       have to call ``set_test_cookie()`` on a previous, separate page request.
       See "Setting test cookies" below for more information.
 
     * ``delete_test_cookie()``
+
       Deletes the test cookie. Use this to clean up after yourself.
 
+    * ``set_expiry(value)``
+
+      **New in Django development version**
+
+      Sets the expiration time for the session. You can pass a number of
+      different values:
+
+            * If ``value`` is an integer, the session will expire after that
+              many seconds of inactivity. For example, calling
+              ``request.session.set_expiry(300)`` would make the session expire
+              in 5 minutes.
+
+            * If ``value`` is a ``datetime`` or ``timedelta`` object, the
+              session will expire at that specific date/time.
+
+            * If ``value`` is ``0``, the user's session cookie will expire
+              when the user's Web browser is closed.
+
+            * If ``value`` is ``None``, the session reverts to using the global
+              session expiry policy.
+
+    * ``get_expiry_age()``
+
+      **New in Django development version**
+
+      Returns the number of seconds until this session expires. For sessions
+      with no custom expiration (or those set to expire at browser close), this
+      will equal ``settings.SESSION_COOKIE_AGE``.
+
+    * ``get_expiry_date()``
+
+      **New in Django development version**
+
+      Returns the date this session will expire. For sessions with no custom
+      expiration (or those set to expire at browser close), this will equal the
+      date ``settings.SESSION_COOKIE_AGE`` seconds from now.
+
+    * ``get_expire_at_browser_close()``
+
+      **New in Django development version**
+
+      Returns either ``True`` or ``False``, depending on whether the user's
+      session cookie will expire when the user's Web browser is closed.
+
 You can edit ``request.session`` at any point in your view. You can edit it
 multiple times.
 
@@ -278,6 +330,12 @@ browser-length cookies -- cookies that expire as soon as the user closes his or
 her browser. Use this if you want people to have to log in every time they open
 a browser.
 
+**New in Django development version**
+
+This setting is a global default and can be overwritten at a per-session level
+by explicitly calling ``request.session.set_expiry()`` as described above in
+`using sessions in views`_.
+
 Clearing the session table
 ==========================
 
diff --git a/docs/settings.txt b/docs/settings.txt
index 9b89c92343..02e458fcda 100644
--- a/docs/settings.txt
+++ b/docs/settings.txt
@@ -394,6 +394,8 @@ site with ``DEBUG`` turned on.
 DEBUG_PROPAGATE_EXCEPTIONS
 --------------------------
 
+**New in Django development version**
+
 Default: ``False``
 
 If set to True, Django's normal exception handling of view functions
diff --git a/docs/testing.txt b/docs/testing.txt
index 0ff3cce3d9..befa6979af 100644
--- a/docs/testing.txt
+++ b/docs/testing.txt
@@ -822,6 +822,10 @@ useful for testing Web applications:
     that ``text`` appears in the content of the response. If ``count`` is
     provided, ``text`` must occur exactly ``count`` times in the response.
 
+``assertNotContains(response, text, status_code=200)``
+    Asserts that a ``Response`` instance produced the given ``status_code`` and
+    that ``text`` does not appears in the content of the response.
+
 ``assertFormError(response, form, field, errors)``
     Asserts that a field on a form raises the provided list of errors when
     rendered on the form.
@@ -837,6 +841,12 @@ useful for testing Web applications:
     ``errors`` is an error string, or a list of error strings, that are
     expected as a result of form validation.
 
+``assertTemplateUsed(response, template_name)``
+    Asserts that the template with the given name was used in rendering the
+    response.
+
+    The name is a string such as ``'admin/index.html'``.
+
 ``assertTemplateNotUsed(response, template_name)``
     Asserts that the template with the given name was *not* used in rendering
     the response.
@@ -846,12 +856,6 @@ useful for testing Web applications:
     it redirected to ``expected_url`` (including any GET data), and the subsequent
     page was received with ``target_status_code``.
 
-``assertTemplateUsed(response, template_name)``
-    Asserts that the template with the given name was used in rendering the
-    response.
-
-    The name is a string such as ``'admin/index.html'``.
-
 E-mail services
 ---------------