[gsoc2009-testing] Upstream Merge

git-svn-id: http://code.djangoproject.com/svn/django/branches/soc2009/test-improvements@11293 bcc190cf-cafb-0310-a4f2-bffc1f526a37

6 files changed, 63 insertions, 36 deletions

diff --git a/docs/index.txt b/docs/index.txt
index abf5580c60..abe6416da3 100644
--- a/docs/index.txt
+++ b/docs/index.txt
@@ -202,6 +202,7 @@ The Django open-source project
 
     * **Django over time:**
       :ref:`API stability <misc-api-stability>` |
-      :ref:`Archive of release notes <releases-index>` | `Backwards-incompatible changes`_
+      :ref:`Archive of release notes <releases-index>` | `Backwards-incompatible changes`_ |
+      :ref:`Deprecation Timeline <internals-deprecation>`
 
 .. _Backwards-incompatible changes: http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges
diff --git a/docs/internals/committers.txt b/docs/internals/committers.txt
index 002c7f5ab8..9f77e98c07 100644
--- a/docs/internals/committers.txt
+++ b/docs/internals/committers.txt
@@ -154,6 +154,19 @@ Gary Wilson
     broken windows. He's continued to do that necessary tidying up work
     throughout the code base since then.
 
+Justin Bronn
+    Justin Bronn is a computer scientist and attorney specializing
+    in legal topics related to intellectual property and spatial law.
+
+    In 2007, Justin began developing ``django.contrib.gis`` in a branch,
+    a.k.a. GeoDjango_, which was merged in time for Django 1.0.  While
+    implementing GeoDjango, Justin obtained a deep knowledge of Django's
+    internals including the ORM, the admin, and Oracle support.
+
+    Justin lives in Houston, Texas.
+
+.. _GeoDjango: http://geodjango.org/
+
 Karen Tracey
     Karen has a background in distributed operating systems (graduate school),
     communications software (industry) and crossword puzzle construction
@@ -187,16 +200,6 @@ Ian Kelly
 Matt Boersma
     Matt is also responsible for Django's Oracle support.
 
-Justin Bronn
-    Justin Bronn is a computer scientist and third-year law student at the
-    University of Houston who enjoys studying legal topics related to
-    intellectual property and spatial law.
-
-    Justin is the primary developer of ``django.contrib.gis``, a.k.a.
-    GeoDjango_.
-
-.. _GeoDjango: http://geodjango.org/
-
 Jeremy Dunck
     Jeremy the lead developer of Pegasus News, a personalized local site based
     in Dallas, Texas. An early contributor to Greasemonkey and Django, he sees
diff --git a/docs/internals/deprecation.txt b/docs/internals/deprecation.txt
new file mode 100644
index 0000000000..7e7f4c6338
--- /dev/null
+++ b/docs/internals/deprecation.txt
@@ -0,0 +1,21 @@
+.. _internals-deprecation:
+
+===========================
+Django Deprecation Timeline
+===========================
+
+This document outlines when various pieces of Django will be removed, following
+their deprecation, as per the :ref:`Django deprecation policy
+<internal-release-deprecation-policy>`
+
+    * 1.3
+        * ``AdminSite.root()``.  This release will remove the old method for
+          hooking up admin URLs.  This has been deprecated since the 1.1
+          release.
+
+    * 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.
diff --git a/docs/internals/index.txt b/docs/internals/index.txt
index 0d54948bf5..1cbbb87f06 100644
--- a/docs/internals/index.txt
+++ b/docs/internals/index.txt
@@ -17,8 +17,9 @@ the hood".
 
 .. toctree::
    :maxdepth: 1
-   
+
    contributing
    documentation
    committers
    release-process
+   deprecation
diff --git a/docs/internals/release-process.txt b/docs/internals/release-process.txt
index 911b67e441..6d4ad9e8c9 100644
--- a/docs/internals/release-process.txt
+++ b/docs/internals/release-process.txt
@@ -48,14 +48,16 @@ Minor releases
 --------------
 
 Minor release (1.1, 1.2, etc.) will happen roughly every six months -- see
-`release process`_, below for details. 
+`release process`_, below for details.
+
+.. _internal-release-deprecation-policy:
 
 These releases will contain new features, improvements to existing features, and
 such. A minor release may deprecate certain features from previous releases. If a
 feature in version ``A.B`` is deprecated, it will continue to work in version
 ``A.B+1``. In version ``A.B+2``, use of the feature will raise a
 ``PendingDeprecationWarning`` but will continue to work. Version ``A.B+3`` will
-remove the feature entirely. 
+remove the feature entirely.
 
 So, for example, if we decided to remove a function that existed in Django 1.0:
 
@@ -66,9 +68,9 @@ So, for example, if we decided to remove a function that existed in Django 1.0:
     * Django 1.2 will contain the backwards-compatible replica, but the warning
       will be promoted to a full-fledged ``DeprecationWarning``. This warning is
       *loud* by default, and will likely be quite annoying.
-      
+
     * Django 1.3 will remove the feature outright.
-    
+
 Micro releases
 --------------
 
@@ -92,21 +94,21 @@ varying levels:
 
     * The current development trunk will get new features and bug fixes
       requiring major refactoring.
-    
+
     * All bug fixes applied to the trunk will also be applied to the last
       minor release, to be released as the next micro release.
-      
+
     * Security fixes will be applied to the current trunk and the previous two
       minor releases.
-      
+
 As a concrete example, consider a moment in time halfway between the release of
 Django 1.3 and 1.4. At this point in time:
 
     * Features will be added to development trunk, to be released as Django 1.4.
-    
+
     * Bug fixes will be applied to a ``1.3.X`` branch, and released as 1.3.1,
       1.3.2, etc.
-      
+
     * Security releases will be applied to trunk, a ``1.3.X`` branch and a
       ``1.2.X`` branch. Security fixes will trigger the release of ``1.3.1``,
       ``1.2.1``, etc.
@@ -117,7 +119,7 @@ Release process
 ===============
 
 Django uses a time-based release schedule, with minor (i.e. 1.1, 1.2, etc.)
-releases every six months, or more, depending on features. 
+releases every six months, or more, depending on features.
 
 After each previous release (and after a suitable cooling-off period of a week
 or two), the core development team will examine the landscape and announce a
@@ -174,12 +176,12 @@ and an rc complete with string freeze two weeks before the end of the schedule.
 Bug-fix releases
 ----------------
 
-After a minor release (i.e 1.1), the previous release will go into bug-fix mode. 
+After a minor release (i.e 1.1), the previous release will go into bug-fix mode.
 
 A branch will be created of the form ``branches/releases/1.0.X`` to track
 bug-fixes to the previous release. When possible, bugs fixed on trunk must
 *also* be fixed on the bug-fix branch; this means that commits need to cleanly
-separate bug fixes from feature additions. The developer who commits a fix to 
+separate bug fixes from feature additions. The developer who commits a fix to
 trunk will be responsible for also applying the fix to the current bug-fix
 branch.  Each bug-fix branch will have a maintainer who will work with the
 committers to keep them honest on backporting bug fixes.
@@ -193,14 +195,13 @@ development will be happening in a bunch of places:
 
     * On trunk, development towards 1.2 proceeds with small additions, bugs
       fixes, etc. being checked in daily.
-      
+
     * On the branch "branches/releases/1.1.X", bug fixes found in the 1.1
       release are checked in as needed. At some point, this branch will be
       released as "1.1.1", "1.1.2", etc.
 
     * On the branch "branches/releases/1.0.X", security fixes are made if
       needed and released as "1.0.2", "1.0.3", etc.
-    
+
     * On feature branches, development of major features is done. These
       branches will be merged into trunk before the end of phase two.
-
diff --git a/docs/topics/http/urls.txt b/docs/topics/http/urls.txt
index b2e99dce7f..0b2257cefe 100644
--- a/docs/topics/http/urls.txt
+++ b/docs/topics/http/urls.txt
@@ -465,7 +465,7 @@ Defining URL Namespaces
 
 When you need to deploy multiple instances of a single application, it can be
 helpful to be able to differentiate between instances. This is especially
-important when using _`named URL patterns <naming-url-patterns>`, since
+important when using :ref:`named URL patterns <naming-url-patterns>`, since
 multiple instances of a single application will share named URLs. Namespaces
 provide a way to tell these named URLs apart.
 
@@ -642,7 +642,7 @@ view::
 
 This is completely valid, but it leads to problems when you try to do reverse
 URL matching (through the ``permalink()`` decorator or the :ttag:`url` template
-tag. Continuing this example, if you wanted to retrieve the URL for the
+tag). Continuing this example, if you wanted to retrieve the URL for the
 ``archive`` view, Django's reverse URL matcher would get confused, because *two*
 URLpatterns point at that view.
 
@@ -706,12 +706,12 @@ the fully qualified name into parts, and then tries the following lookup:
        example, ``myapp``). This will yield a list of instances of that
        application.
 
-    2. If there is a ``current`` application defined, Django finds and returns
-       the URL resolver for that instance. The ``current`` can be specified
-       as an attribute on the template context - applications that expect to
-       have multiple deployments should set the ``current_app`` attribute on
-       any ``Context`` or ``RequestContext`` that is used to render a
-       template.
+    2. If there is a *current* application defined, Django finds and returns
+       the URL resolver for that instance. The *current* application can be
+       specified as an attribute on the template context - applications that
+       expect to have multiple deployments should set the ``current_app``
+       attribute on any ``Context`` or ``RequestContext`` that is used to
+       render a template.
 
        The current application can also be specified manually as an argument
        to the :func:`reverse()` function.
@@ -725,7 +725,7 @@ the fully qualified name into parts, and then tries the following lookup:
        deployed instance of the application, whatever its instance name may be.
 
     5. If the provided namespace doesn't match an application namespace in
-       step 2, Django will attempt a direct lookup of the namespace as an
+       step 1, Django will attempt a direct lookup of the namespace as an
        instance namespace.
 
 If there are nested namespaces, these steps are repeated for each part of the