Merge branch 'master' into schema-alteration

Conflicts:
	django/db/backends/__init__.py
	django/db/backends/mysql/base.py
	django/db/backends/oracle/base.py
	django/db/backends/oracle/creation.py
	django/db/backends/postgresql_psycopg2/base.py
	django/db/backends/sqlite3/base.py
	django/db/models/fields/related.py

7 files changed, 124 insertions, 104 deletions

diff --git a/docs/internals/contributing/committing-code.txt b/docs/internals/contributing/committing-code.txt
index 67dda02f8b..bc2f97a485 100644
--- a/docs/internals/contributing/committing-code.txt
+++ b/docs/internals/contributing/committing-code.txt
@@ -116,7 +116,7 @@ Practicality beats purity, so it is up to each committer to decide how much
 history mangling to do for a pull request. The main points are engaging the
 community, getting work done, and having a usable commit history.
 
-.. _committing-guidlines:
+.. _committing-guidelines:
 
 Committing guidelines
 ---------------------
diff --git a/docs/internals/contributing/new-contributors.txt b/docs/internals/contributing/new-contributors.txt
index b752503248..0d4ad0cf3f 100644
--- a/docs/internals/contributing/new-contributors.txt
+++ b/docs/internals/contributing/new-contributors.txt
@@ -140,12 +140,3 @@ FAQ
    Short answer: No. It's always better to get another set of eyes on a
    ticket. If you're having trouble getting that second set of eyes, see
    question 1, above.
-
-3. **My ticket has been in DDN forever! What should I do?**
-
-   Design Decision Needed requires consensus about the right solution.  At the
-   very least it needs consensus among the core developers, and ideally it has
-   consensus from the community as well. The best way to accomplish this is to
-   start a thread on the django-developers mailing list, and for very complex
-   issues to start a wiki page summarizing the problem and the possible
-   solutions.
diff --git a/docs/internals/contributing/triaging-tickets.txt b/docs/internals/contributing/triaging-tickets.txt
index 84f70fd731..bc6148ca46 100644
--- a/docs/internals/contributing/triaging-tickets.txt
+++ b/docs/internals/contributing/triaging-tickets.txt
@@ -50,9 +50,9 @@ attribute easily tells us what and who each ticket is waiting on.
 
 Since a picture is worth a thousand words, let's start there:
 
-.. image:: /internals/_images/djangotickets.png
-   :height: 451
-   :width: 590
+.. image:: /internals/_images/triage_process.*
+   :height: 501
+   :width: 400
    :alt: Django's ticket triage workflow
 
 We've got two roles in this diagram:
@@ -119,7 +119,14 @@ Beyond that there are several considerations:
 * **Accepted + No Flags**
 
   The ticket is valid, but no one has submitted a patch for it yet. Often this
-  means you could safely start writing a patch for it.
+  means you could safely start writing a patch for it. This is generally more
+  true for the case of accepted bugs than accepted features. A ticket for a bug
+  that has been accepted means that the issue has been verified by at least one
+  triager as a legitimate bug - and should probably be fixed if possible. An
+  accepted new feature may only mean that one triager thought the feature would
+  be good to have, but this alone does not represent a consensus view or imply
+  with any certainty that a patch will be accepted for that feature. Seek more
+  feedback before writing an extensive patch if you are in doubt.
 
 * **Accepted + Has Patch**
 
@@ -128,30 +135,13 @@ Beyond that there are several considerations:
   and docs, running the test suite with the included patch, and leaving
   feedback on the ticket.
 
-* **Accepted + Has Patch + (any other flag)**
+* **Accepted + Has Patch + Needs ...**
 
   This means the ticket has been reviewed, and has been found to need further
   work. "Needs tests" and "Needs documentation" are self-explanatory. "Patch
   needs improvement" will generally be accompanied by a comment on the ticket
   explaining what is needed to improve the code.
 
-Design Decision Needed
-~~~~~~~~~~~~~~~~~~~~~~
-
-This stage is for issues which may be contentious, may be backwards
-incompatible, or otherwise involve high-level design decisions. These issues
-should be discussed either in the ticket comments or on `django-developers`_.
-
-If a ticket has been marked as "DDN", decisions are generally eventually
-made by the core committers, however that is not a requirement. See the
-:ref:`New contributors' FAQ<new-contributors-faq>` for "My ticket has been in
-DDN forever! What should I do?"
-
-This stage will often 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 stage and move straight to "Accepted".
-
 Ready For Checkin
 ~~~~~~~~~~~~~~~~~
 
@@ -165,39 +155,54 @@ RFC forever! What should I do?"
 Someday/Maybe
 ~~~~~~~~~~~~~
 
-Generally only used for vague/high-level features or design ideas. These
-tickets are uncommon and overall less useful since they don't describe
+This stage isn't shown on the diagram. It's only used by core developers to
+keep track of high-level ideas or long term feature requests.
+
+These tickets are uncommon and overall less useful since they don't describe
 concrete actionable issues. They are enhancement requests that we might
 consider adding someday to the framework if an excellent patch is submitted.
-These tickets are not a high priority.
+They are not a high priority.
 
 Other triage attributes
 -----------------------
 
 A number of flags, appearing as checkboxes in Trac, can be set on a ticket:
 
-* Has patch
-    This means the ticket has an associated
-    :doc:`patch<writing-code/submitting-patches>`. These will be reviewed
-    to see if the patch is "good".
+Has patch
+~~~~~~~~~
+
+This means the ticket has an associated
+:doc:`patch<writing-code/submitting-patches>`. These will be reviewed
+to see if the patch is "good".
+
+Needs documentation
+~~~~~~~~~~~~~~~~~~~
 
-* Needs documentation:
-    This flag is used for tickets with patches that need associated
-    documentation. Complete documentation of features is a prerequisite
-    before we can check them into the codebase.
+This flag is used for tickets with patches that need associated
+documentation. Complete documentation of features is a prerequisite
+before we can check them into the codebase.
 
-* Needs tests
-    This flags the patch as needing associated unit tests. Again, this
-    is a required part of a valid patch.
+Needs tests
+~~~~~~~~~~~
 
-* Patch needs improvement
-    This flag means that although the ticket *has* a patch, it's not quite
-    ready for checkin. This could mean the patch no longer applies
-    cleanly, there is a flaw in the implementation, or that the code
-    doesn't meet our standards.
+This flags the patch as needing associated unit tests. Again, this
+is a required part of a valid patch.
 
-* Easy pickings
-    Tickets that would require small, easy, patches.
+Patch needs improvement
+~~~~~~~~~~~~~~~~~~~~~~~
+
+This flag means that although the ticket *has* a patch, it's not quite
+ready for checkin. This could mean the patch no longer applies
+cleanly, there is a flaw in the implementation, or that the code
+doesn't meet our standards.
+
+Easy pickings
+~~~~~~~~~~~~~
+
+Tickets that would require small, easy, patches.
+
+Type
+~~~~
 
 Tickets should be categorized by *type* between:
 
@@ -211,19 +216,47 @@ Tickets should be categorized by *type* between:
     For when nothing is broken but something could be made cleaner,
     better, faster, stronger.
 
-Tickets should also be classified into *components* indicating which area of
+Component
+~~~~~~~~~
+
+Tickets should be classified into *components* indicating which area of
 the Django codebase they belong to. This makes tickets better organized and
 easier to find.
 
+Severity
+~~~~~~~~
+
 The *severity* attribute is used to identify blockers, that is, issues which
 should get fixed before releasing the next version of Django. Typically those
 issues are bugs causing regressions from earlier versions or potentially
 causing severe data losses. This attribute is quite rarely used and the vast
 majority of tickets have a severity of "Normal".
 
-Finally, it is possible to use the *version* attribute to indicate in which
+Version
+~~~~~~~
+
+It is possible to use the *version* attribute to indicate in which
 version the reported bug was identified.
 
+UI/UX
+~~~~~
+
+This flag is used for tickets that relate to User Interface and User
+Experiences questions. For example, this flag would be appropriate for
+user-facing features in forms or the admin interface.
+
+Cc
+~~
+
+You may add your username or email address to this field to be notified when
+new contributions are made to the ticket.
+
+Keywords
+~~~~~~~~
+
+With this field you may label a ticket with multiple keywords. This can be
+useful, for example, to group several tickets of a same theme.
+
 .. _closing-tickets:
 
 Closing Tickets
@@ -301,20 +334,23 @@ developers and bring the issue to django-developers_ instead.
 How can I help with triaging?
 -----------------------------
 
-Although the core developers make the big decisions in the ticket triage
-process, there's a lot that general community members can do to help the
-triage process. Really, **ANYONE** can help.
+The triage process is primarily driven by community members. Really,
+**ANYONE** can help.
+
+Core developers may provide feedback on issues they're familiar with, or make
+decisions on controversial ones, but they aren't responsible for triaging
+tickets in general.
 
-Start by `creating an account on Trac`_. If you have an account but have
-forgotten your password, you can reset it using the `password reset page`_.
+To get involved, start by `creating an account on Trac`_. If you have an
+account but have forgotten your password, you can reset it using the `password
+reset page`_.
 
 Then, you can help out by:
 
 * Closing "Unreviewed" tickets as "invalid", "worksforme" or "duplicate."
 
-* Promoting "Unreviewed" tickets to "Design decision needed" if a design
-  decision needs to be made, or "Accepted" in case of obvious bugs or
-  sensible, clearly defined, feature requests.
+* Closing "Unreviewed" tickets as "needsinfo" when they're feature requests
+  requiring a discussion on `django-developers`_.
 
 * Correcting the "Needs tests", "Needs documentation", or "Has patch"
   flags for tickets where they are incorrectly set.
@@ -322,22 +358,18 @@ Then, you can help out by:
 * Setting the "`Easy pickings`_" flag for tickets that are small and
   relatively straightforward.
 
+* Set the *type* of tickets that are still uncategorized.
+
 * 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 yet been closed.
 
-* Contacting 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 may indicate we should
   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`_.
 
-* Set the *type* of tickets that are still uncategorized.
-
 * Verify if patches submitted by other users are correct. If they do and
   also contain appropriate documentation and tests then move them to the
   "Ready for Checkin" stage. If they don't then leave a comment to explain
diff --git a/docs/internals/contributing/writing-code/coding-style.txt b/docs/internals/contributing/writing-code/coding-style.txt
index a699e39bd8..21146600b4 100644
--- a/docs/internals/contributing/writing-code/coding-style.txt
+++ b/docs/internals/contributing/writing-code/coding-style.txt
@@ -136,14 +136,17 @@ Model style
   * ``def get_absolute_url()``
   * Any custom methods
 
-* If ``choices`` is defined for a given model field, define the choices as
-  a tuple of tuples, with an all-uppercase name, either near the top of
-  the model module or just above the model class. Example::
+* If ``choices`` is defined for a given model field, define each choice as
+  a tuple of tuples, with an all-uppercase name as a class attribute on the
+  model. Example::
 
-      DIRECTION_CHOICES = (
-          ('U', 'Up'),
-          ('D', 'Down'),
-      )
+    class MyModel(models.Model):
+        DIRECTION_UP = 'U'
+        DIRECTION_DOWN = 'D'
+        DIRECTION_CHOICES = (
+            (DIRECTION_UP, 'Up'),
+            (DIRECTION_DOWN, 'Down'),
+        )
 
 Use of ``django.conf.settings``
 -------------------------------
@@ -177,9 +180,9 @@ That means that the ability for third parties to import the module at the top
 level is incompatible with the ability to configure the settings object
 manually, or makes it very difficult in some circumstances.
 
-Instead of the above code, a level of laziness or indirection must be used, such
-as :class:`django.utils.functional.LazyObject`,
-:func:`django.utils.functional.lazy` or ``lambda``.
+Instead of the above code, a level of laziness or indirection must be used,
+such as ``django.utils.functional.LazyObject``,
+``django.utils.functional.lazy()`` or ``lambda``.
 
 Miscellaneous
 -------------
diff --git a/docs/internals/contributing/writing-code/submitting-patches.txt b/docs/internals/contributing/writing-code/submitting-patches.txt
index a90dc32605..ed8aad99b3 100644
--- a/docs/internals/contributing/writing-code/submitting-patches.txt
+++ b/docs/internals/contributing/writing-code/submitting-patches.txt
@@ -176,8 +176,10 @@ Compressing JavaScript
 ~~~~~~~~~~~~~~~~~~~~~~
 
 To simplify the process of providing optimized javascript code, Django
-includes a handy script which should be used to create a "minified" version.
-This script is located at ``django/contrib/admin/static/admin/js/compress.py``.
+includes a handy python script which should be used to create a "minified"
+version. To run it::
+
+    python django/contrib/admin/bin/compress.py
 
 Behind the scenes, ``compress.py`` is a front-end for Google's
 `Closure Compiler`_ which is written in Java. However, the Closure Compiler
diff --git a/docs/internals/contributing/writing-code/unit-tests.txt b/docs/internals/contributing/writing-code/unit-tests.txt
index 4e702ff83e..f56bf1cdeb 100644
--- a/docs/internals/contributing/writing-code/unit-tests.txt
+++ b/docs/internals/contributing/writing-code/unit-tests.txt
@@ -7,16 +7,14 @@ code base. It's our policy to make sure all tests pass at all times.
 
 The tests cover:
 
-* Models and the database API (``tests/modeltests``),
-* Everything else in core Django code (``tests/regressiontests``),
-* :ref:`contrib-apps` (``django/contrib/<app>/tests`` or
-  ``tests/regressiontests/<app>_...``).
+* Models, the database API and everything else in core Django core (``tests/``),
+* :ref:`contrib-apps` (``django/contrib/<app>/tests`` or ``tests/<app>_...``).
 
 We appreciate any and all contributions to the test suite!
 
 The Django tests all use the testing infrastructure that ships with Django for
-testing applications. See :doc:`Testing Django applications </topics/testing>`
-for an explanation of how to write new tests.
+testing applications. See :doc:`Testing Django applications
+</topics/testing/overview>` for an explanation of how to write new tests.
 
 .. _running-unit-tests:
 
@@ -105,9 +103,9 @@ internationalization, type:
 
     ./runtests.py --settings=path.to.settings generic_relations i18n
 
-How do you find out the names of individual tests? Look in
-``tests/modeltests`` and ``tests/regressiontests`` — each directory name
-there is the name of a test. Contrib app names are also valid test names.
+How do you find out the names of individual tests? Look in ``tests/`` — each
+directory name there is the name of a test. Contrib app names are also valid
+test names.
 
 If you just want to run a particular class of tests, you can specify a list of
 paths to individual test classes. For example, to run the ``TranslationTests``
@@ -128,13 +126,13 @@ Running the Selenium tests
 
 Some admin tests require Selenium 2, Firefox and Python >= 2.6 to work via a
 real Web browser. To allow those tests to run and not be skipped, you must
-install the selenium_ package (version > 2.13) into your Python path.
-
-Then, run the tests normally, for example:
+install the selenium_ package (version > 2.13) into your Python path and run
+the tests with the ``--selenium`` option:
 
 .. code-block:: bash
 
-    ./runtests.py --settings=test_sqlite admin_inlines
+    ./runtests.py --settings=test_sqlite --selenium admin_inlines
+
 
 .. _running-unit-tests-dependencies:
 
@@ -145,9 +143,6 @@ If you want to run the full suite of tests, you'll need to install a number of
 dependencies:
 
 *  PyYAML_
-*  Markdown_
-*  Textile_
-*  Docutils_
 *  setuptools_
 *  memcached_, plus a :ref:`supported Python binding <memcached>`
 *  gettext_ (:ref:`gettext_on_windows`)
@@ -160,9 +155,6 @@ Each of these dependencies is optional. If you're missing any of them, the
 associated tests will be skipped.
 
 .. _PyYAML: http://pyyaml.org/wiki/PyYAML
-.. _Markdown: http://pypi.python.org/pypi/Markdown/1.7
-.. _Textile: http://pypi.python.org/pypi/textile
-.. _docutils: http://pypi.python.org/pypi/docutils/0.4
 .. _setuptools: http://pypi.python.org/pypi/setuptools/
 .. _memcached: http://memcached.org/
 .. _gettext: http://www.gnu.org/software/gettext/manual/gettext.html
@@ -200,7 +192,7 @@ multiple modules by using a ``tests`` directory in the normal Python way.
 For the tests to be found, a ``models.py`` file must exist, even if it's empty.
 If you have URLs that need to be mapped, put them in ``tests/urls.py``.
 
-To run tests for just one contrib app (e.g. ``markup``), use the same
+To run tests for just one contrib app (e.g. ``auth``), use the same
 method as above::
 
-    ./runtests.py --settings=settings markup
+    ./runtests.py --settings=settings auth
diff --git a/docs/internals/contributing/writing-code/working-with-git.txt b/docs/internals/contributing/writing-code/working-with-git.txt
index d4a95ae45a..dcfdd9e85b 100644
--- a/docs/internals/contributing/writing-code/working-with-git.txt
+++ b/docs/internals/contributing/writing-code/working-with-git.txt
@@ -81,7 +81,7 @@ commit them::
     git commit
 
 When writing the commit message, follow the :ref:`commit message
-guidelines <committing-guidlines>` to ease the work of the committer. If
+guidelines <committing-guidelines>` to ease the work of the committer. If
 you're uncomfortable with English, try at least to describe precisely what the
 commit does.
 
@@ -121,7 +121,7 @@ a pull request at GitHub. A good pull request means:
 
 * well-formed messages for each commit: a summary line and then paragraphs
   wrapped at 72 characters thereafter -- see the :ref:`committing guidelines
-  <committing-guidlines>` for more details,
+  <committing-guidelines>` for more details,
 
 * documentation and tests, if needed -- actually tests are always needed,
   except for documentation changes.