Code

Ticket #16469: 16469.diff

File 16469.diff, 65.5 KB (added by aaugustin, 3 years ago)
Line 
1Index: docs/internals/contributing/translations.txt
2===================================================================
3--- docs/internals/contributing/translations.txt        (révision 16544)
4+++ docs/internals/contributing/translations.txt        (copie de travail)
5@@ -3,24 +3,29 @@
6 =======================================
7 
8 Various parts of Django, such as the admin site and validation error messages,
9-are internationalized. This means they display different text depending on a
10-user's language setting. For this, Django uses the same internationalization
11-infrastructure available to Django applications described in the
12+are internationalized. This means they display different text depending on each
13+user's language setting. For this, Django uses the same internationalization and
14+localization infrastructure available to Django applications, described in the
15 :doc:`i18n documentation</topics/i18n/index>`.
16 
17-These translations are contributed by Django users worldwide. If you find an
18-incorrect translation or want to discuss specific translations, go to the
19-`translation team`_ page for that language. If you would like to help out
20-with translating or add a language that isn't yet translated, here's what
21-to do:
22+Internationalization
23+--------------------
24 
25+Translations are contributed by Django users worldwide. The translation work is
26+coordinated at `Transifex`_.
27+
28+If you find an incorrect translation or want to discuss specific translations,
29+go to the `translation team`_ page for that language. If you would like to help
30+out with translating or add a language that isn't yet translated, here's what to
31+do:
32+
33     * Join the `Django i18n mailing list`_ and introduce yourself.
34 
35     * Make sure you read the notes about :ref:`specialties-of-django-i18n`.
36 
37     * Signup at `Transifex`_ and visit the `Django project page`_.
38 
39-    * On the "`Translation Teams`_" page, choose the language team you want
40+    * On the `translation teams`_ page, choose the language team you want
41       to work with, **or** -- in case the language team doesn't exist yet --
42       request a new team by clicking on the "Request a new team" button
43       and select the appropriate language.
44@@ -37,24 +42,27 @@
45       Each of the contrib apps also have a resource (prefixed with "contrib").
46 
47       .. note::
48-         For more information about how to use Transifex, see the
49-         `Transifex Help`_
50+         For more information about how to use Transifex, read the
51+         `Transifex User Guide`_.
52 
53-    * Optionally, review and update the ``conf/locale/<locale>/formats.py``
54-      file to describe the date, time and numbers formatting particularities
55-      of your locale. These files aren't covered by the use of Transifex and
56-      require a patch against the Django source tree, just as a code change
57-      would:
58+Localization
59+------------
60 
61-      * Create a diff against the current Subversion trunk.
62+You can also review ``conf/locale/<locale>/formats.py``. This file describes
63+the date, time and numbers formatting particularities of your locale. See
64+:ref:`format-localization` for details.
65 
66-      * Open a ticket in Django's ticket system, set its ``Component`` field
67-        to ``Translations``, and attach the patch to it. See
68-        :ref:`format-localization` for details.
69+The format files aren't managed by the use of Transifex. To change them, you
70+must :doc:`create a patch<writing-code/submitting-patches>` against the Django source tree, as for any code change:
71 
72+    * Create a diff against the current Subversion trunk.
73+
74+    * Open a ticket in Django's ticket system, set its ``Component`` field to
75+      ``Translations``, and attach the patch to it.
76+
77+.. _Transifex: http://www.transifex.net/
78 .. _Django i18n mailing list: http://groups.google.com/group/django-i18n/
79-.. _Transifex: http://www.transifex.net/
80 .. _Django project page: http://www.transifex.net/projects/p/django/
81+.. _translation team: http://www.transifex.net/projects/p/django/teams/
82 .. _translation teams: http://www.transifex.net/projects/p/django/teams/
83-.. _translation team: http://www.transifex.net/projects/p/django/teams/
84-.. _Transifex Help: http://help.transifex.net/
85+.. _Transifex User Guide: http://help.transifex.net/
86Index: docs/internals/contributing/committing-code.txt
87===================================================================
88--- docs/internals/contributing/committing-code.txt     (révision 16544)
89+++ docs/internals/contributing/committing-code.txt     (copie de travail)
90@@ -28,12 +28,10 @@
91     in question is likely to be sufficient.
92 
93 Decisions on new committers will follow the process explained in
94-:ref:`how-we-make-decisions`.
95+:ref:`how-we-make-decisions`. To request commit access, please contact an
96+existing committer privately. Public requests for commit access are potential
97+flame-war starters, and will be ignored.
98 
99-To request commit access, please contact an existing committer privately.
100-Public requests for commit access are potential flame-war starters, and
101-will be ignored.
102-
103 Committing guidelines
104 ---------------------
105 
106@@ -69,12 +67,12 @@
107 
108     * Separate bug fixes from feature changes.
109 
110-      Bug fixes need to be added to the current bugfix branch (e.g. the
111-      ``1.0.X`` branch) as well as the current trunk.
112+      Bug fixes need to be added to the current bugfix branch as well as the
113+      current trunk.
114 
115     * If your commit closes a ticket in the Django `ticket tracker`_, begin
116       your commit message with the text "Fixed #abc", where "abc" is the
117-      number of the ticket your commit fixes. Example: "Fixed #123 -- Adde
118+      number of the ticket your commit fixes. Example: "Fixed #123 -- Added
119       support for foo". We've rigged Subversion and Trac so that any commit
120       message in that format will automatically close the referenced ticket
121       and post a comment to it with the full commit message.
122@@ -83,7 +81,7 @@
123       first, then the "Fixed #abc." For example:
124       "magic-removal: Fixed #123 -- Added whizbang feature."
125 
126-      For the curious: We're using a `Trac post-commit hook`_ for this.
127+      For the curious: we're using a `Trac post-commit hook`_ for this.
128 
129       .. _Trac post-commit hook: http://trac.edgewall.org/browser/trunk/contrib/trac-post-commit-hook
130 
131@@ -111,8 +109,8 @@
132 
133     * If the original author can't be reached (within a reasonable amount
134       of time -- a day or so) and the problem is severe -- crashing bug,
135-      major test failures, etc -- then ask for objections on django-dev
136-      then revert if there are none.
137+      major test failures, etc -- then ask for objections on the
138+      `django-developers`_ mailing list then revert if there are none.
139 
140     * If the problem is small (a feature commit after feature freeze,
141       say), wait it out.
142Index: docs/internals/contributing/new-contributors.txt
143===================================================================
144--- docs/internals/contributing/new-contributors.txt    (révision 16544)
145+++ docs/internals/contributing/new-contributors.txt    (copie de travail)
146@@ -5,15 +5,14 @@
147 New contributor and not sure what to do? Want to help but just don't know how
148 to get started? This is the section for you.
149 
150-* **Pick a subject area that you care about, that you are familiar with, or
151-  that you want to learn about**
152+First steps
153+-----------
154 
155-  You don't already have to be an expert on the area you want to work on; you
156-  become an expert through your ongoing contributions to the code.
157+Start with these easy tasks to discover Django's development process.
158 
159 * **Triage tickets**
160 
161-  If a ticket is unreviewed and reports a bug, try and reproduce it. If you
162+  If an `unreviewed ticket`_ reports a bug, try and reproduce it. If you
163   can reproduce it and it seems valid, make a note that you confirmed the bug
164   and accept the ticket. Make sure the ticket is filed under the correct
165   component area. Consider writing a patch that adds a test for the bug's
166@@ -44,8 +43,31 @@
167   :doc:`writing-documentation`, in particular the tips for
168   :ref:`improving-the-documentation`.
169 
170-* **Analyze the ticket's context and history**
171+  .. note::
172 
173+      The `reports page`_ contains links to many useful Trac queries, including
174+      several that are useful for triaging tickets and reviewing patches as
175+      suggested above.
176+
177+      .. _reports page: http://code.djangoproject.com/wiki/Reports
178+
179+.. _unreviewed ticket: http://code.djangoproject.com/query?status=!closed&stage=Unreviewed
180+
181+
182+Guidelines
183+----------
184+
185+As a newcomer on a large project, it's easy to experience frustration. Here's
186+some advice to make your work on Django more useful and rewarding.
187+
188+* **Pick a subject area that you care about, that you are familiar with, or
189+  that you want to learn about**
190+
191+  You don't already have to be an expert on the area you want to work on; you
192+  become an expert through your ongoing contributions to the code.
193+
194+* **Analyze tickets' context and history**
195+
196   Trac isn't an absolute; the context is just as important as the words.
197   When reading Trac, you need to take into account who says things, and when
198   they were said. Support for an idea two years ago doesn't necessarily mean
199@@ -96,14 +118,8 @@
200   writing the very first tests for that feature, not that you get a pass from
201   writing tests altogether.
202 
203-.. note::
204+.. _easy pickings: http://code.djangoproject.com/query?status=!closed&easy=1
205 
206-    The `Reports page`_ contains links to many useful Trac queries, including
207-    several that are useful for triaging tickets and reviewing patches as
208-    suggested above.
209-
210-    .. _Reports page: http://code.djangoproject.com/wiki/Reports
211-
212 .. _new-contributors-faq:
213 
214 FAQ
215@@ -114,7 +130,7 @@
216 
217    First off, it's not personal. Django is entirely developed by volunteers
218    (even the core developers), and sometimes folks just don't have time. The
219-   best thing to do is to send a gentle reminder to the Django Developers
220+   best thing to do is to send a gentle reminder to the django-developers
221    mailing list asking for review on the ticket, or to bring it up in the
222    #django-dev IRC channel.
223 
224@@ -130,8 +146,6 @@
225    Design Decision Needed requires consensus about the right solution.  At the
226    very least it needs consensus among the core developers, and ideally it has
227    consensus from the community as well. The best way to accomplish this is to
228-   start a thread on the Django Developers mailing list, and for very complex
229+   start a thread on the django-developers mailing list, and for very complex
230    issues to start a wiki page summarizing the problem and the possible
231    solutions.
232-
233-.. _`easy pickings`: http://code.djangoproject.com/query?status=!closed&easy=1
234Index: docs/internals/contributing/index.txt
235===================================================================
236--- docs/internals/contributing/index.txt       (révision 16544)
237+++ docs/internals/contributing/index.txt       (copie de travail)
238@@ -2,34 +2,52 @@
239 Contributing to Django
240 ======================
241 
242+Django is a community that lives on its volunteers. As it keeps growing, we
243+always need more people to help others. As soon as you learn Django, you can
244+contribute in many ways:
245+
246+    * Join the `django-users`_ mailing list and answer questions. This
247+      mailing list has a huge audience, and we really want to maintain a
248+      friendly and helpful atmosphere. If you're new to the Django community,
249+      you should read the `posting guidelines`_.
250+
251+    * Join the `#django IRC channel`_ on Freenode and answer questions. By
252+      explaining Django to other users, you're going to learn a lot about the
253+      framework yourself.
254+
255+    * Blog about Django. We syndicate all the Django blogs we know about on
256+      the `community page`_; if you'd like to see your blog on that page you
257+      can `register it here`_.
258+
259+    * Contribute to open-source Django projects, write some documentation, or
260+      release your own code as an open-source pluggable application. The
261+      ecosystem of pluggable applications is a big strength of Django, help us
262+      build it!
263+
264 If you think working *with* Django is fun, wait until you start working *on*
265 it. We're passionate about helping Django users make the jump to contributing
266 members of the community, so there are several ways you can help Django's
267 development:
268 
269-    * Blog about Django. We syndicate all the Django blogs we know about on
270-      the `community page`_; if you'd like to see your blog on that page you
271-      can `register it here`_.
272+    * :doc:`Report bugs <bugs-and-features>` in our `ticket tracker`_.
273 
274-    * :doc:`Report bugs and request features<bugs-and-features>` in our
275-      `ticket tracker`_.
276-
277     * Join the `django-developers`_ mailing list and share your ideas for how
278       to improve Django. We're always open to suggestions.
279 
280-    * :doc:`Submit patches<writing-code/submitting-patches>` for new and/or
281+    * :doc:`Submit patches <writing-code/submitting-patches>` for new and/or
282       fixed behavior. If you're looking for an easy way to start contributing
283       to Django have a look at the `easy pickings`_ tickets.
284 
285-    * :doc:`Improve the documentation<writing-documentation>` or
286-      :doc:`write unit tests<writing-code/unit-tests>`.
287+    * :doc:`Improve the documentation <writing-documentation>` or
288+      :doc:`write unit tests <writing-code/unit-tests>`.
289 
290-    * :doc:`Triage tickets<triaging-tickets>` that have been created by other
291-      users.
292+    * :doc:`Triage tickets and review patches <triaging-tickets>` created by
293+      other users.
294 
295-... and many more ways! Really, **ANYONE** can do something to help make
296-Django better and greater. Browse the following sections to find out how:
297+Really, **ANYONE** can do something to help make Django better and greater!
298 
299+Browse the following sections to find out how:
300+
301 .. toctree::
302    :maxdepth: 2
303 
304@@ -41,8 +59,11 @@
305    translations
306    committing-code
307 
308+.. _django-users: http://groups.google.com/group/django-users
309+.. _posting guidelines: https://code.djangoproject.com/wiki/UsingTheMailingList
310+.. _#django IRC channel: irc://irc.freenode.net/django
311+.. _community page: http://www.djangoproject.com/community/
312+.. _register it here: http://www.djangoproject.com/community/add/blogs/
313 .. _django-developers: http://groups.google.com/group/django-developers
314 .. _ticket tracker: http://code.djangoproject.com/newticket
315-.. _community page: http://www.djangoproject.com/community/
316-.. _`easy pickings`: http://code.djangoproject.com/query?status=!closed&easy=1
317-.. _`register it here`: http://www.djangoproject.com/community/add/blogs/
318+.. _easy pickings: http://code.djangoproject.com/query?status=!closed&easy=1
319Index: docs/internals/contributing/triaging-tickets.txt
320===================================================================
321--- docs/internals/contributing/triaging-tickets.txt    (révision 16544)
322+++ docs/internals/contributing/triaging-tickets.txt    (copie de travail)
323@@ -2,16 +2,17 @@
324 Triaging tickets
325 ================
326 
327-Django uses Trac_ for managing our progress, and Trac is a community-tended
328-garden of the bugs people have found and the features people would like to see
329-added. As in any garden, sometimes there are weeds to be pulled and sometimes
330-there are flowers and vegetables that need picking. We need your help to sort
331-out one from the other, and in the end we all benefit together.
332+Django uses Trac_ for managing the work on the code base. Trac is a
333+community-tended garden of the bugs people have found and the features people
334+would like to see added. As in any garden, sometimes there are weeds to be
335+pulled and sometimes there are flowers and vegetables that need picking. We need
336+your help to sort out one from the other, and in the end we all benefit
337+together.
338 
339 Like all gardens, we can aspire to perfection but in reality there's no such
340 thing. Even in the most pristine garden there are still snails and insects.
341-In a community garden there are also helpful people who--with the best of
342-intentions--fertilize the weeds and poison the roses. It's the job of the
343+In a community garden there are also helpful people who -- with the best of
344+intentions -- fertilize the weeds and poison the roses. It's the job of the
345 community as a whole to self-manage, keep the problems to a minimum, and
346 educate those coming into the community so that they can become valuable
347 contributing members.
348@@ -39,8 +40,8 @@
349 :ref:`good patch<patch-style>`.
350 
351 One way to help out is to *triage* tickets that have been created by other
352-users. The core team--as well as many community members--work on this
353-regularly, but more help is always appreciated.
354+users. The core team and several community members work on this regularly, but
355+more help is always appreciated.
356 
357 Most of the workflow is based around the concept of a ticket's
358 :ref:`triage stages <triage-stages>`. Each stage describes where in its
359@@ -146,11 +147,10 @@
360 :ref:`New contributors' FAQ<new-contributors-faq>` for "My ticket has been in
361 DDN forever! What should I do?"
362 
363-This stage will generally only be used for feature
364-requests. It can also be used for issues that *might* be bugs, depending on
365-opinion or interpretation. Obvious bugs (such as crashes, incorrect query
366-results, or non-compliance with a standard) skip this stage and move straight
367-to "Accepted".
368+This stage will often be used for feature requests. It can also be used for
369+issues that *might* be bugs, depending on opinion or interpretation. Obvious
370+bugs (such as crashes, incorrect query results, or non-compliance with a
371+standard) skip this stage and move straight to "Accepted".
372 
373 Ready For Checkin
374 ~~~~~~~~~~~~~~~~~
375@@ -200,7 +200,7 @@
376         This flag means that although the ticket *has* a patch, it's not quite
377         ready for checkin. This could mean the patch no longer applies
378         cleanly, there is a flaw in the implementation, or that the code
379-        doesn't meet our standards."
380+        doesn't meet our standards.
381   * Easy pickings
382         Tickets that would require small, easy, patches.
383 
384@@ -250,7 +250,7 @@
385   * If there is a way they can improve the ticket to reopen it, let them know.
386 
387   * If the ticket is a duplicate, reference the original ticket. Also
388-    cross-reference the closed ticket by living a comment in the original one
389+    cross-reference the closed ticket by leaving a comment in the original one
390     -- this allows to access more related information about the reported bug
391     or requested feature.
392 
393@@ -279,7 +279,7 @@
394         discussion in the `django-developers`_ mailing list. Feel free to
395         start or join in discussions of "wontfix" tickets on the
396         django-developers_ mailing list, but please do not reopen tickets
397-        closed as "wontfix" by core developers.
398+        closed as "wontfix" by a :doc:`core developer</internals/committers>`.
399 
400   * duplicate
401         Used when another ticket covers the same issue. By closing duplicate
402@@ -371,9 +371,9 @@
403       checkin", but you should get at minimum one other community member to
404       review a patch that you submit.
405 
406-    * Please **don't** reverse a decision that has been made by a core
407-      developer. If you disagree with a decision that has been made,
408-      please post a message to `django-developers`_.
409+    * Please **don't** reverse a decision that has been made by a :doc:`core
410+      developer</internals/committers>`. If you disagree with a decision that
411+      has been made, please post a message to `django-developers`_.
412 
413     * If you're unsure if you should be making a change, don't make the
414       change but instead leave a comment with your concerns on the ticket,
415Index: docs/internals/contributing/writing-documentation.txt
416===================================================================
417--- docs/internals/contributing/writing-documentation.txt       (révision 16544)
418+++ docs/internals/contributing/writing-documentation.txt       (copie de travail)
419@@ -9,10 +9,10 @@
420 
421 Documentation changes generally come in two forms:
422 
423-    * General improvements -- Typo corrections, error fixes and better
424+    * General improvements: typo corrections, error fixes and better
425       explanations through clearer writing and more examples.
426 
427-    * New features -- Documentation of features that have been added to the
428+    * New features: documentation of features that have been added to the
429       framework since the last release.
430 
431 This section explains how writers can craft their documentation changes
432@@ -61,17 +61,13 @@
433 
434     * **email** -- no hyphen.
435 
436-    * **MySQL**
437+    * **MySQL**, **PostgreSQL**, **SQLite**
438 
439-    * **PostgreSQL**
440-
441     * **Python** -- when referring to the language, capitalize Python.
442 
443     * **realize**, **customize**, **initialize**, etc. -- use the American
444       "ize" suffix, not "ise."
445 
446-    * **SQLite**
447-
448     * **subclass** -- it's a single word without a hyphen, both as a verb
449       ("subclass that model") and as a noun ("create a subclass").
450 
451@@ -168,10 +164,10 @@
452 
453 Our policy for new features is:
454 
455-    **All documentation of new features should be written in a way that
456+    All documentation of new features should be written in a way that
457     clearly designates the features are only available in the Django
458     development version. Assume documentation readers are using the latest
459-    release, not the development version.**
460+    release, not the development version.
461 
462 Our preferred way for marking new features is by prefacing the features'
463 documentation with: "``.. versionadded:: X.Y``", followed by an optional one
464Index: docs/internals/contributing/bugs-and-features.txt
465===================================================================
466--- docs/internals/contributing/bugs-and-features.txt   (révision 16544)
467+++ docs/internals/contributing/bugs-and-features.txt   (copie de travail)
468@@ -2,14 +2,14 @@
469 Reporting bugs and requesting features
470 ======================================
471 
472-Before reporting a bug or requesting a new feature please consider these
473+Before reporting a bug or requesting a new feature, please consider these
474 general points:
475 
476 * Check that someone hasn't already filed the bug or feature request by
477   `searching`_ or running `custom queries`_ in the ticket tracker.
478 
479 * Don't use the ticket system to ask support questions. Use the
480-  `django-users`_ list, or the `#django`_ IRC channel for that.
481+  `django-users`_ list or the `#django`_ IRC channel for that.
482 
483 * Don't reopen issues that have been marked "wontfix" by a core developer.
484   This mark means that the decision has been made that we can't or won't fix
485@@ -17,7 +17,7 @@
486   on `django-developers`_.
487 
488 * Don't use the ticket tracker for lengthy discussions, because they're
489-  likely to get lost. If a particular ticket is controversial, please move
490+  likely to get lost. If a particular ticket is controversial, please move the
491   discussion to `django-developers`_.
492 
493 .. _reporting-bugs:
494@@ -33,19 +33,19 @@
495     * **Do** read the :doc:`FAQ </faq/index>` to see if your issue might
496       be a well-known question.
497 
498-    * **Do** ask on `django-users`_ *first* if you're not sure if what you're
499-      seeing is a bug.
500+    * **Do** ask on `django-users`_ or `#django`_ *first* if you're not sure if
501+      what you're seeing is a bug.
502 
503-    * **Do** write complete, reproducible, specific bug reports. Include as
504-      much information as you possibly can, complete with code snippets, test
505-      cases, etc. This means including a clear, concise description of the
506-      problem, and a clear set of instructions for replicating the problem.
507-      A minimal example that illustrates the bug in a nice small test case
508-      is the best possible bug report.
509+    * **Do** write complete, reproducible, specific bug reports. You must
510+      include a clear, concise description of the problem, and a set of
511+      instructions for replicating it. Add as much debug information as you can:
512+      code snippets, test cases, exception backtraces, screenshots, etc. A nice
513+      small test case is the best way to report a bug, as it gives us an easy
514+      way to confirm the bug quickly.
515 
516-    * **Don't** post to django-developers just to announce that you have filed
517-      a bug report. All the tickets are mailed to another list
518-      (`django-updates`_), which is tracked by developers and interested
519+    * **Don't** post to `django-developers`_ just to announce that you have
520+      filed a bug report. All the tickets are mailed to another list,
521+      `django-updates`_, which is tracked by developers and interested
522       community members; we see them as they are filed.
523 
524 To understand the lifecycle of your ticket once you have created it, refer to
525@@ -95,9 +95,19 @@
526 We're always trying to make Django better, and your feature requests are a key
527 part of that. Here are some tips on how to make a request most effectively:
528 
529-    * First request the feature on `django-developers`_, not in the ticket
530-      tracker. It'll get read more closely if it's on the mailing list.
531+    * Make sure the feature actually requires changes in Django's core. If your
532+      idea can be developed as an independent application or module — for
533+      instance, you want to support another database engine — we'll probably
534+      suggest that you to develop it independently. Then, if your project
535+      gathers sufficient community support, we may consider it for inclusion in
536+      Django.
537 
538+    * First request the feature on the `django-developers`_ list, not in the
539+      ticket tracker. It'll get read more closely if it's on the mailing list.
540+      This is even more important for large-scale feature requests. We like to
541+      discuss any big changes to Django's core on the mailing list before
542+      actually working on them.
543+
544     * Describe clearly and concisely what the missing feature is and how you'd
545       like to see it implemented. Include example code (non-functional is OK)
546       if possible.
547@@ -107,19 +117,16 @@
548       you'll need to explain it, if it isn't obvious why the feature would be
549       useful.
550 
551-    * Don't use the ticket system to make large-scale feature requests.
552-      We like to discuss any big changes to Django's core on the
553-      `django-developers`_ list before actually working on them.
554+If core developers agree on the feature, then it's appropriate to create a
555+ticket. Include a link the discussion on `django-developers`_ in the ticket
556+description.
557 
558 As with most open-source projects, code talks. If you are willing to write the
559-code for the feature yourself or if (even better) you've already written it,
560+code for the feature yourself or, even better, if you've already written it,
561 it's much more likely to be accepted. If it's a large feature that might need
562 multiple developers, we're always happy to give you an experimental branch in
563 our repository; see the :doc:`writing-code/branch-policy`.
564 
565-To understand the lifecycle of your ticket once you have created it, refer to
566-:doc:`triaging-tickets`.
567-
568 See also: :ref:`documenting-new-features`.
569 
570 .. _how-we-make-decisions:
571@@ -141,9 +148,9 @@
572     * -1: "I strongly disagree and would be very unhappy to see the idea turn
573       into reality."
574 
575-Although these votes on django-developers are informal, they'll be taken very
576-seriously. After a suitable voting period, if an obvious consensus arises
577-we'll follow the votes.
578+Although these votes on `django-developers`_ are informal, they'll be taken very
579+seriously. After a suitable voting period, if an obvious consensus arises we'll
580+follow the votes.
581 
582 However, consensus is not always possible. If consensus cannot be reached, or
583 if the discussion towards a consensus fizzles out without a concrete decision,
584@@ -175,7 +182,7 @@
585 
586 
587 .. _searching: http://code.djangoproject.com/search
588-.. _`custom queries`: https://code.djangoproject.com/query
589+.. _custom queries: https://code.djangoproject.com/query
590 .. _django-developers: http://groups.google.com/group/django-developers
591 .. _django-users: http://groups.google.com/group/django-users
592-.. _`#django`: irc://irc.freenode.net/django
593+.. _#django: irc://irc.freenode.net/django
594Index: docs/internals/contributing/writing-code/coding-style.txt
595===================================================================
596--- docs/internals/contributing/writing-code/coding-style.txt   (révision 16544)
597+++ docs/internals/contributing/writing-code/coding-style.txt   (copie de travail)
598@@ -9,7 +9,7 @@
599 
600     * Unless otherwise specified, follow :pep:`8`.
601 
602-      You could use a tool like `pep8.py`_ to check for some problems in this
603+      You could use a tool like `pep8`_ to check for some problems in this
604       area, but remember that PEP 8 is only a guide, so respect the style of
605       the surrounding code as a primary goal.
606 
607@@ -171,9 +171,9 @@
608 level is incompatible with the ability to configure the settings object
609 manually, or makes it very difficult in some circumstances.
610 
611-Instead of the above code, a level of laziness or indirection must be used,
612-such as `django.utils.functional.LazyObject``, ``django.utils.functional.lazy``
613-or ``lambda``.
614+Instead of the above code, a level of laziness or indirection must be used, such
615+as :class:`django.utils.functional.LazyObject`,
616+:func:`django.utils.functional.lazy` or ``lambda``.
617 
618 Miscellaneous
619 -------------
620@@ -181,10 +181,15 @@
621     * Mark all strings for internationalization; see the :doc:`i18n
622       documentation </topics/i18n/index>` for details.
623 
624+    * Remove ``import`` statements that are no longer used when you change code.
625+      The most common tools for this task are `pyflakes`_ and `pylint`_.
626+
627     * Please don't put your name in the code you contribute. Our policy is to
628       keep contributors' names in the ``AUTHORS`` file distributed with Django
629       -- not scattered throughout the codebase itself. Feel free to include a
630       change to the ``AUTHORS`` file in your patch if you make more than a
631       single trivial change.
632 
633-.. _pep8.py: http://pypi.python.org/pypi/pep8/
634+.. _pep8: http://pypi.python.org/pypi/pep8
635+.. _pyflakes: http://pypi.python.org/pypi/pyflakes
636+.. _pylint: http://pypi.python.org/pypi/pylint
637Index: docs/internals/contributing/writing-code/branch-policy.txt
638===================================================================
639--- docs/internals/contributing/writing-code/branch-policy.txt  (révision 16544)
640+++ docs/internals/contributing/writing-code/branch-policy.txt  (copie de travail)
641@@ -146,15 +146,14 @@
642 location of the branch's ``django`` package. If you want to switch back, just
643 change the symlink to point to the old code.
644 
645-A third option is to use a `path file`_ (``<something>.pth``) which should
646-work on all systems (including Windows, which doesn't have symlinks
647-available). First, make sure there are no files, directories or symlinks named
648-``django`` in your ``site-packages`` directory. Then create a text file named
649-``django.pth`` and save it to your ``site-packages`` directory. That file
650-should contain a path to your copy of Django on a single line and optional
651-comments. Here is an example that points to multiple branches. Just uncomment
652-the line for the branch you want to use ('Trunk' in this example) and make
653-sure all other lines are commented::
654+A third option is to use a `path file`_ (``<something>.pth``). First, make sure
655+there are no files, directories or symlinks named ``django`` in your
656+``site-packages`` directory. Then create a text file named ``django.pth`` and
657+save it to your ``site-packages`` directory. That file should contain a path to
658+your copy of Django on a single line and optional comments. Here is an example
659+that points to multiple branches. Just uncomment the line for the branch you
660+want to use ('Trunk' in this example) and make sure all other lines are
661+commented::
662 
663     # Trunk is a svn checkout of:
664     #   http://code.djangoproject.com/svn/django/trunk/
665Index: docs/internals/contributing/writing-code/submitting-patches.txt
666===================================================================
667--- docs/internals/contributing/writing-code/submitting-patches.txt     (révision 16544)
668+++ docs/internals/contributing/writing-code/submitting-patches.txt     (copie de travail)
669@@ -84,7 +84,7 @@
670       Patches in ``git diff`` format are also acceptable.
671 
672     * When creating patches, always run ``svn diff`` from the top-level
673-      ``trunk`` directory -- i.e., the one that contains ``django``, ``docs``,
674+      ``trunk`` directory -- i.e. the one that contains ``django``, ``docs``,
675       ``tests``, ``AUTHORS``, etc. This makes it easy for other people to
676       apply your patches.
677 
678@@ -101,8 +101,8 @@
679 
680     * The code required to fix a problem or add a feature is an essential part
681       of a patch, but it is not the only part. A good patch should also
682-      include a regression test to validate the behavior that has been fixed
683-      (and prevent the problem from arising again).
684+      include a regression test to validate the behavior that has been fixed,
685+      to prevent the problem from arising again.
686 
687     * If the code associated with a patch adds a new feature, or modifies
688       behavior of an existing feature, the patch should also contain
689@@ -130,13 +130,13 @@
690 best practice in this regard.
691 
692 To that end, patches for javascript files should include both the original
693-code for future development (e.g. "foo.js"), and a compressed version for
694-production use (e.g. "foo.min.js"). Any links to the file in the codebase
695+code for future development (e.g. ``foo.js``), and a compressed version for
696+production use (e.g. ``foo.min.js``). Any links to the file in the codebase
697 should point to the compressed version.
698 
699 To simplify the process of providing optimized javascript code, Django
700 includes a handy script which should be used to create a "minified" version.
701-This script is located at ``/contrib/admin/media/js/compress.py``.
702+This script is located at ``django/contrib/admin/static/js/compress.py``.
703 
704 Behind the scenes, ``compress.py`` is a front-end for Google's
705 `Closure Compiler`_ which is written in Java. However, the Closure Compiler
706@@ -148,7 +148,7 @@
707 higher on Mac OS X). Note that Mac OS X 10.5 and earlier did not ship with
708 Java 1.6 by default, so it may be necessary to upgrade your Java installation
709 before the tool will be functional. Also note that even after upgrading Java,
710-the default `/usr/bin/java` command may remain linked to the previous Java
711+the default ``/usr/bin/java`` command may remain linked to the previous Java
712 binary, so relinking that command may be necessary as well.
713 
714 Please don't forget to run ``compress.py`` and include the ``diff`` of the
715Index: docs/internals/contributing/writing-code/unit-tests.txt
716===================================================================
717--- docs/internals/contributing/writing-code/unit-tests.txt     (révision 16544)
718+++ docs/internals/contributing/writing-code/unit-tests.txt     (copie de travail)
719@@ -3,13 +3,13 @@
720 ==========
721 
722 Django comes with a test suite of its own, in the ``tests`` directory of the
723-Django tarball. It's our policy to make sure all tests pass at all times.
724+code base. It's our policy to make sure all tests pass at all times.
725 
726 The tests cover:
727 
728-    * Models and the database API (``tests/modeltests/``).
729-    * Everything else in core Django code (``tests/regressiontests``)
730-    * Contrib apps (``django/contrib/<contribapp>/tests``, see below)
731+    * Models and the database API (``tests/modeltests``),
732+    * Everything else in core Django code (``tests/regressiontests``),
733+    * :ref:`contrib-apps` (``django/contrib/<app>/tests``).
734 
735 We appreciate any and all contributions to the test suite!
736 
737@@ -105,8 +105,8 @@
738     ./runtests.py --settings=path.to.settings generic_relations i18n
739 
740 How do you find out the names of individual tests? Look in
741-``tests/modeltests`` and ``tests/regressiontests`` -- each directory name
742-there is the name of a test.
743+``tests/modeltests`` and ``tests/regressiontests`` — each directory name
744+there is the name of a test. Contrib app names are also valid test names.
745 
746 If you just want to run a particular class of tests, you can specify a list of
747 paths to individual test classes. For example, to run the ``TranslationTests``
748@@ -150,16 +150,17 @@
749 .. _memcached: http://www.danga.com/memcached/
750 .. _gettext: http://www.gnu.org/software/gettext/manual/gettext.html
751 
752+.. _contrib-apps:
753+
754 Contrib apps
755 ------------
756 
757-Tests for apps in ``django/contrib/`` go in their respective directories under
758-``django/contrib/``, in a ``tests.py`` file. (You can split the tests over
759-multiple modules by using a ``tests`` directory in the normal Python way.)
760+Tests for contrib apps go in their respective directories under
761+``django/contrib``, in a ``tests.py`` file. You can split the tests over
762+multiple modules by using a ``tests`` directory in the normal Python way.
763 
764-For the tests to be found, a ``models.py`` file must exist (it doesn't
765-have to have anything in it). If you have URLs that need to be
766-mapped, put them in ``tests/urls.py``.
767+For the tests to be found, a ``models.py`` file must exist, even if it's empty.
768+If you have URLs that need to be mapped, put them in ``tests/urls.py``.
769 
770 To run tests for just one contrib app (e.g. ``markup``), use the same
771 method as above::
772Index: docs/internals/release-process.txt
773===================================================================
774--- docs/internals/release-process.txt  (révision 16544)
775+++ docs/internals/release-process.txt  (copie de travail)
776@@ -7,30 +7,30 @@
777 Official releases
778 =================
779 
780-Django's release numbering works as follows:
781+Since version 1.0, Django's release numbering works as follows:
782 
783     * Versions are numbered in the form ``A.B`` or ``A.B.C``.
784 
785     * ``A`` is the *major version* number, which is only incremented for major
786       changes to Django, and these changes are not necessarily
787-      backwards-compatible. That is, code you wrote for Django 6.0 may break
788-      when we release Django 7.0.
789+      backwards-compatible. That is, code you wrote for Django 1.2 may break
790+      when we release Django 2.0.
791 
792     * ``B`` is the *minor version* number, which is incremented for large yet
793-      backwards compatible changes.  Code written for Django 6.4 will continue
794-      to work under Django 6.5.
795+      backwards compatible changes.  Code written for Django 1.2 will continue
796+      to work under Django 1.3. Exceptions to this rule will be listed in the
797+      release notes.
798 
799-    * ``C`` is the *micro version* number which, is incremented for bug and
800-      security fixes.  A new micro-release will always be 100%
801-      backwards-compatible with the previous micro-release.
802+    * ``C`` is the *micro version* number, which is incremented for bug and
803+      security fixes. A new micro-release will be 100% backwards-compatible with
804+      the previous micro-release. The only exception is when a security issue
805+      can't be fixed without breaking backwards-compatibility. If this happens,
806+      the release notes will provide detailed upgrade instructions.
807 
808     * In some cases, we'll make alpha, beta, or release candidate releases.
809       These are of the form ``A.B alpha/beta/rc N``, which means the ``Nth``
810       alpha/beta/release candidate of version ``A.B``.
811 
812-An exception to this version numbering scheme is the pre-1.0 Django code.
813-There's no guarantee of backwards-compatibility until the 1.0 release.
814-
815 In Subversion, each Django release will be tagged under ``tags/releases``.  If
816 it's necessary to release a bug fix release or a security release that doesn't
817 come from the trunk, we'll copy that tag to ``branches/releases`` to make the
818@@ -75,9 +75,9 @@
819 Micro releases (1.0.1, 1.0.2, 1.1.1, etc.) will be issued at least once half-way
820 between minor releases, and probably more often as needed.
821 
822-These releases will always be 100% compatible with the associated minor release
823--- the answer to "should I upgrade to the latest micro release?" will always be
824-"yes."
825+These releases will be 100% compatible with the associated minor release, unless
826+this is impossible for security reasons. So the answer to "should I upgrade to
827+the latest micro release?" will always be "yes."
828 
829 Each minor release of Django will have a "release maintainer" appointed. This
830 person will be responsible for making sure that bug fixes are applied to both
831@@ -93,9 +93,21 @@
832     * The current development trunk will get new features and bug fixes
833       requiring major refactoring.
834 
835-    * All bug fixes applied to the trunk will also be applied to the last
836-      minor release, to be released as the next micro release.
837+    * Patches applied to the trunk will also be applied to the last minor
838+      release, to be released as the next micro release, when they fix critical
839+      problems:
840 
841+      * Security issues.
842+
843+      * Data-loss bugs.
844+
845+      * Crashing bugs.
846+
847+      * Major functionality bugs in newly-introduced features.
848+
849+      The rule of thumb is that fixes will be backported to the last minor
850+      release for bugs that would have prevented a release in the first place.
851+
852     * Security fixes will be applied to the current trunk and the previous two
853       minor releases.
854 
855@@ -104,12 +116,12 @@
856 
857     * Features will be added to development trunk, to be released as Django 1.4.
858 
859-    * Bug fixes will be applied to a ``1.3.X`` branch, and released as 1.3.1,
860-      1.3.2, etc.
861+    * Critical bug fixes will be applied to a ``1.3.X`` branch, and released as
862+      1.3.1, 1.3.2, etc.
863 
864-    * Security releases will be applied to trunk, a ``1.3.X`` branch and a
865-      ``1.2.X`` branch. Security fixes will trigger the release of ``1.3.1``,
866-      ``1.2.1``, etc.
867+    * Security fixes will be applied to trunk, a ``1.3.X`` branch and a
868+      ``1.2.X`` branch. They will trigger the release of ``1.3.1``, ``1.2.1``,
869+      etc.
870 
871 .. _release-process:
872 
873@@ -119,11 +131,11 @@
874 Django uses a time-based release schedule, with minor (i.e. 1.1, 1.2, etc.)
875 releases every nine months, or more, depending on features.
876 
877-After each previous release (and after a suitable cooling-off period of a week
878-or two), the core development team will examine the landscape and announce a
879-timeline for the next release. Most releases will be scheduled in the 6-9 month
880-range, but if we have bigger features to development we might schedule a longer
881-period to allow for more ambitious work.
882+After each release, and after a suitable cooling-off period of a few weeks, the
883+core development team will examine the landscape and announce a timeline for the
884+next release. Most releases will be scheduled in the 6-9 month range, but if we
885+have bigger features to development we might schedule a longer period to allow
886+for more ambitious work.
887 
888 Release cycle
889 -------------
890@@ -174,10 +186,11 @@
891 Bug-fix releases
892 ----------------
893 
894-After a minor release (i.e 1.1), the previous release will go into bug-fix mode.
895+After a minor release (e.g. 1.1), the previous release will go into bug-fix
896+mode.
897 
898 A branch will be created of the form ``branches/releases/1.0.X`` to track
899-bug-fixes to the previous release. When possible, bugs fixed on trunk must
900+bug-fixes to the previous release. Critical bugs fixed on trunk must
901 *also* be fixed on the bug-fix branch; this means that commits need to cleanly
902 separate bug fixes from feature additions. The developer who commits a fix to
903 trunk will be responsible for also applying the fix to the current bug-fix
904@@ -194,9 +207,9 @@
905     * On trunk, development towards 1.2 proceeds with small additions, bugs
906       fixes, etc. being checked in daily.
907 
908-    * On the branch "branches/releases/1.1.X", bug fixes found in the 1.1
909-      release are checked in as needed. At some point, this branch will be
910-      released as "1.1.1", "1.1.2", etc.
911+    * On the branch "branches/releases/1.1.X", fixes for critical bugs found in
912+      the 1.1 release are checked in as needed. At some point, this branch will
913+      be released as "1.1.1", "1.1.2", etc.
914 
915     * On the branch "branches/releases/1.0.X", security fixes are made if
916       needed and released as "1.0.2", "1.0.3", etc.
917Index: docs/internals/deprecation.txt
918===================================================================
919--- docs/internals/deprecation.txt      (révision 16544)
920+++ docs/internals/deprecation.txt      (copie de travail)
921@@ -3,232 +3,242 @@
922 ===========================
923 
924 This document outlines when various pieces of Django will be removed, following
925-their deprecation, as per the :ref:`Django deprecation policy
926-<internal-release-deprecation-policy>`
927+their deprecation, as per the :ref:`deprecation policy
928+<internal-release-deprecation-policy>`.
929 
930-    * 1.3
931-        * ``AdminSite.root()``.  This release will remove the old method for
932-          hooking up admin URLs.  This has been deprecated since the 1.1
933-          release.
934+1.3
935+---
936 
937-        * Authentication backends need to define the boolean attributes
938-          ``supports_object_permissions`` and ``supports_anonymous_user``.
939-          The old backend style is deprecated since the 1.2 release.
940+    * ``AdminSite.root()``.  This release will remove the old method for
941+      hooking up admin URLs.  This has been deprecated since the 1.1
942+      release.
943 
944-        * The :mod:`django.contrib.gis.db.backend` module, including the
945-          ``SpatialBackend`` interface, is deprecated since the 1.2 release.
946+    * Authentication backends need to define the boolean attributes
947+      ``supports_object_permissions`` and ``supports_anonymous_user``.
948+      The old backend style is deprecated since the 1.2 release.
949 
950-    * 1.4
951-        * ``CsrfResponseMiddleware``.  This has been deprecated since the 1.2
952-          release, in favor of the template tag method for inserting the CSRF
953-          token.  ``CsrfMiddleware``, which combines ``CsrfResponseMiddleware``
954-          and ``CsrfViewMiddleware``, is also deprecated.
955+    * The :mod:`django.contrib.gis.db.backend` module, including the
956+      ``SpatialBackend`` interface, is deprecated since the 1.2 release.
957 
958-        * The old imports for CSRF functionality (``django.contrib.csrf.*``),
959-          which moved to core in 1.2, will be removed.
960+1.4
961+---
962 
963-        * ``SMTPConnection``. The 1.2 release deprecated the ``SMTPConnection``
964-          class in favor of a generic E-mail backend API.
965+    * ``CsrfResponseMiddleware``.  This has been deprecated since the 1.2
966+      release, in favor of the template tag method for inserting the CSRF
967+      token.  ``CsrfMiddleware``, which combines ``CsrfResponseMiddleware``
968+      and ``CsrfViewMiddleware``, is also deprecated.
969 
970-        * The many to many SQL generation functions on the database backends
971-          will be removed.
972+    * The old imports for CSRF functionality (``django.contrib.csrf.*``),
973+      which moved to core in 1.2, will be removed.
974 
975-        * The ability to use the ``DATABASE_*`` family of top-level settings to
976-          define database connections will be removed.
977+    * ``SMTPConnection``. The 1.2 release deprecated the ``SMTPConnection``
978+      class in favor of a generic E-mail backend API.
979 
980-        * The ability to use shorthand notation to specify a database backend
981-          (i.e., ``sqlite3`` instead of ``django.db.backends.sqlite3``) will be
982-          removed.
983+    * The many to many SQL generation functions on the database backends
984+      will be removed.
985 
986-        * The ``get_db_prep_save``, ``get_db_prep_value`` and
987-          ``get_db_prep_lookup`` methods on Field were modified in 1.2
988-          to support multiple databases. In 1.4, the support functions
989-          that allow methods with the old prototype to continue
990-          working will be removed.
991+    * The ability to use the ``DATABASE_*`` family of top-level settings to
992+      define database connections will be removed.
993 
994-        * The ``Message`` model (in ``django.contrib.auth``), its related
995-          manager in the ``User`` model (``user.message_set``), and the
996-          associated methods (``user.message_set.create()`` and
997-          ``user.get_and_delete_messages()``), which have
998-          been deprecated since the 1.2 release, will be removed.  The
999-          :doc:`messages framework </ref/contrib/messages>` should be used
1000-          instead. The related ``messages`` variable returned by the
1001-          auth context processor will also be removed. Note that this
1002-          means that the admin application depends on the messages
1003-          context processor.
1004+    * The ability to use shorthand notation to specify a database backend
1005+      (i.e., ``sqlite3`` instead of ``django.db.backends.sqlite3``) will be
1006+      removed.
1007 
1008-        * Authentication backends need to support the ``obj`` parameter for
1009-          permission checking. The ``supports_object_permissions`` variable
1010-          is not checked any longer and can be removed.
1011+    * The ``get_db_prep_save``, ``get_db_prep_value`` and
1012+      ``get_db_prep_lookup`` methods on Field were modified in 1.2
1013+      to support multiple databases. In 1.4, the support functions
1014+      that allow methods with the old prototype to continue
1015+      working will be removed.
1016 
1017-        * Authentication backends need to support the ``AnonymousUser``
1018-          being passed to all methods dealing with permissions.
1019-          The ``supports_anonymous_user`` variable is not checked any
1020-          longer and can be removed.
1021+    * The ``Message`` model (in ``django.contrib.auth``), its related
1022+      manager in the ``User`` model (``user.message_set``), and the
1023+      associated methods (``user.message_set.create()`` and
1024+      ``user.get_and_delete_messages()``), which have
1025+      been deprecated since the 1.2 release, will be removed.  The
1026+      :doc:`messages framework </ref/contrib/messages>` should be used
1027+      instead. The related ``messages`` variable returned by the
1028+      auth context processor will also be removed. Note that this
1029+      means that the admin application depends on the messages
1030+      context processor.
1031 
1032-        * The ability to specify a callable template loader rather than a
1033-          ``Loader`` class will be removed, as will the ``load_template_source``
1034-          functions that are included with the built in template loaders for
1035-          backwards compatibility. These have been deprecated since the 1.2
1036-          release.
1037+    * Authentication backends need to support the ``obj`` parameter for
1038+      permission checking. The ``supports_object_permissions`` variable
1039+      is not checked any longer and can be removed.
1040 
1041-        * ``django.utils.translation.get_date_formats()`` and
1042-          ``django.utils.translation.get_partial_date_formats()``. These
1043-          functions are replaced by the new locale aware formatting; use
1044-          ``django.utils.formats.get_format()`` to get the appropriate
1045-          formats.
1046+    * Authentication backends need to support the ``AnonymousUser``
1047+      being passed to all methods dealing with permissions.
1048+      The ``supports_anonymous_user`` variable is not checked any
1049+      longer and can be removed.
1050 
1051-        * In ``django.forms.fields``: ``DEFAULT_DATE_INPUT_FORMATS``,
1052-          ``DEFAULT_TIME_INPUT_FORMATS`` and
1053-          ``DEFAULT_DATETIME_INPUT_FORMATS``. Use
1054-          ``django.utils.formats.get_format()`` to get the appropriate
1055-          formats.
1056+    * The ability to specify a callable template loader rather than a
1057+      ``Loader`` class will be removed, as will the ``load_template_source``
1058+      functions that are included with the built in template loaders for
1059+      backwards compatibility. These have been deprecated since the 1.2
1060+      release.
1061 
1062-        * The ability to use a function-based test runners will be removed,
1063-          along with the ``django.test.simple.run_tests()`` test runner.
1064+    * ``django.utils.translation.get_date_formats()`` and
1065+      ``django.utils.translation.get_partial_date_formats()``. These
1066+      functions are replaced by the new locale aware formatting; use
1067+      ``django.utils.formats.get_format()`` to get the appropriate
1068+      formats.
1069 
1070-        * The ``views.feed()`` view and ``feeds.Feed`` class in
1071-          ``django.contrib.syndication`` have been deprecated since the 1.2
1072-          release. The class-based view ``views.Feed`` should be used instead.
1073+    * In ``django.forms.fields``: ``DEFAULT_DATE_INPUT_FORMATS``,
1074+      ``DEFAULT_TIME_INPUT_FORMATS`` and
1075+      ``DEFAULT_DATETIME_INPUT_FORMATS``. Use
1076+      ``django.utils.formats.get_format()`` to get the appropriate
1077+      formats.
1078 
1079-        * ``django.core.context_processors.auth``.  This release will
1080-          remove the old method in favor of the new method in
1081-          ``django.contrib.auth.context_processors.auth``.  This has been
1082-          deprecated since the 1.2 release.
1083+    * The ability to use a function-based test runners will be removed,
1084+      along with the ``django.test.simple.run_tests()`` test runner.
1085 
1086-        * The ``postgresql`` database backend has been deprecated in favor of
1087-          the ``postgresql_psycopg2`` backend.
1088+    * The ``views.feed()`` view and ``feeds.Feed`` class in
1089+      ``django.contrib.syndication`` have been deprecated since the 1.2
1090+      release. The class-based view ``views.Feed`` should be used instead.
1091 
1092-        * The ``no`` language code has been deprecated in favor of the ``nb``
1093-          language code.
1094+    * ``django.core.context_processors.auth``.  This release will
1095+      remove the old method in favor of the new method in
1096+      ``django.contrib.auth.context_processors.auth``.  This has been
1097+      deprecated since the 1.2 release.
1098 
1099-        * Authentication backends need to define the boolean attribute
1100-          ``supports_inactive_user``.
1101+    * The ``postgresql`` database backend has been deprecated in favor of
1102+      the ``postgresql_psycopg2`` backend.
1103 
1104-        * ``django.db.models.fields.XMLField`` will be removed. This was
1105-          deprecated as part of the 1.3 release. An accelerated deprecation
1106-          schedule has been used because the field hasn't performed any role
1107-          beyond that of a simple ``TextField`` since the removal of oldforms.
1108-          All uses of ``XMLField`` can be replaced with ``TextField``.
1109+    * The ``no`` language code has been deprecated in favor of the ``nb``
1110+      language code.
1111 
1112-    * 1.5
1113-        * The ``mod_python`` request handler has been deprecated since the 1.3
1114-          release. The ``mod_wsgi`` handler should be used instead.
1115+    * Authentication backends need to define the boolean attribute
1116+      ``supports_inactive_user``.
1117 
1118-        * The ``template`` attribute on :class:`~django.test.client.Response`
1119-          objects returned by the :ref:`test client <test-client>` has been
1120-          deprecated since the 1.3 release. The
1121-          :attr:`~django.test.client.Response.templates` attribute should be
1122-          used instead.
1123+    * ``django.db.models.fields.XMLField`` will be removed. This was
1124+      deprecated as part of the 1.3 release. An accelerated deprecation
1125+      schedule has been used because the field hasn't performed any role
1126+      beyond that of a simple ``TextField`` since the removal of oldforms.
1127+      All uses of ``XMLField`` can be replaced with ``TextField``.
1128 
1129-        * The features of the :class:`django.test.simple.DjangoTestRunner`
1130-          (including fail-fast and Ctrl-C test termination) can now be provided
1131-          by the unittest-native :class:`TextTestRunner`. The
1132-          :class:`~django.test.simple.DjangoTestRunner` will be removed in
1133-          favor of using the unittest-native class.
1134+1.5
1135+---
1136 
1137-        * The undocumented function
1138-          :func:`django.contrib.formtools.utils.security_hash`
1139-          is deprecated, in favor of :func:`django.contrib.formtools.utils.form_hmac`
1140+    * The ``mod_python`` request handler has been deprecated since the 1.3
1141+      release. The ``mod_wsgi`` handler should be used instead.
1142 
1143-        * The function-based generic views have been deprecated in
1144-          favor of their class-based cousins. The following modules
1145-          will be removed:
1146+    * The ``template`` attribute on :class:`~django.test.client.Response`
1147+      objects returned by the :ref:`test client <test-client>` has been
1148+      deprecated since the 1.3 release. The
1149+      :attr:`~django.test.client.Response.templates` attribute should be
1150+      used instead.
1151 
1152-              * :mod:`django.views.generic.create_update`
1153-              * :mod:`django.views.generic.date_based`
1154-              * :mod:`django.views.generic.list_detail`
1155-              * :mod:`django.views.generic.simple`
1156+    * The features of the :class:`django.test.simple.DjangoTestRunner`
1157+      (including fail-fast and Ctrl-C test termination) can now be provided
1158+      by the unittest-native :class:`TextTestRunner`. The
1159+      :class:`~django.test.simple.DjangoTestRunner` will be removed in
1160+      favor of using the unittest-native class.
1161 
1162-        * The :class:`~django.core.servers.basehttp.AdminMediaHandler` has
1163-          been deprecated in favor of the
1164-          :class:`~django.contrib.staticfiles.handlers.StaticFilesHandler`.
1165+    * The undocumented function
1166+      :func:`django.contrib.formtools.utils.security_hash`
1167+      is deprecated, in favor of :func:`django.contrib.formtools.utils.form_hmac`
1168 
1169-        * The :ttag:`url` and :ttag:`ssi` template tags will be
1170-          modified so that the first argument to each tag is a
1171-          template variable, not an implied string. The new-style
1172-          behavior is provided in the ``future`` template tag library.
1173+    * The function-based generic views have been deprecated in
1174+      favor of their class-based cousins. The following modules
1175+      will be removed:
1176 
1177-        * The :djadmin:`reset` and :djadmin:`sqlreset` management commands
1178-          are deprecated.
1179+          * :mod:`django.views.generic.create_update`
1180+          * :mod:`django.views.generic.date_based`
1181+          * :mod:`django.views.generic.list_detail`
1182+          * :mod:`django.views.generic.simple`
1183 
1184-        * Authentication backends need to support a inactive user
1185-          being passed to all methods dealing with permissions.
1186-          The ``supports_inactive_user`` variable is not checked any
1187-          longer and can be removed.
1188+    * The :class:`~django.core.servers.basehttp.AdminMediaHandler` has
1189+      been deprecated in favor of the
1190+      :class:`~django.contrib.staticfiles.handlers.StaticFilesHandler`.
1191 
1192-        * :meth:`~django.contrib.gis.geos.GEOSGeometry.transform` will raise
1193-          a :class:`~django.contrib.gis.geos.GEOSException` when called
1194-          on a geometry with no SRID value.
1195+    * The :ttag:`url` and :ttag:`ssi` template tags will be
1196+      modified so that the first argument to each tag is a
1197+      template variable, not an implied string. The new-style
1198+      behavior is provided in the ``future`` template tag library.
1199 
1200-        * :class:`~django.http.CompatCookie` will be removed in favor of
1201-          :class:`~django.http.SimpleCookie`.
1202+    * The :djadmin:`reset` and :djadmin:`sqlreset` management commands
1203+      are deprecated.
1204 
1205-        * :class:`django.core.context_processors.PermWrapper` and
1206-          :class:`django.core.context_processors.PermLookupDict`
1207-          will be moved to :class:`django.contrib.auth.context_processors.PermWrapper`
1208-          and :class:`django.contrib.auth.context_processors.PermLookupDict`,
1209-          respectively.
1210+    * Authentication backends need to support a inactive user
1211+      being passed to all methods dealing with permissions.
1212+      The ``supports_inactive_user`` variable is not checked any
1213+      longer and can be removed.
1214 
1215-        * The :setting:`MEDIA_URL` or :setting:`STATIC_URL` settings are
1216-          required to end with a trailing slash to ensure there is a consistent
1217-          way to combine paths in templates.
1218+    * :meth:`~django.contrib.gis.geos.GEOSGeometry.transform` will raise
1219+      a :class:`~django.contrib.gis.geos.GEOSException` when called
1220+      on a geometry with no SRID value.
1221 
1222-    * 1.6
1223-        * The compatibility modules ``django.utils.copycompat`` and
1224-          ``django.utils.hashcompat`` as well as the functions
1225-          ``django.utils.itercompat.all`` and ``django.utils.itercompat.any``
1226-          have been deprecated since the 1.4 release. The native versions
1227-          should be used instead.
1228+    * :class:`~django.http.CompatCookie` will be removed in favor of
1229+      :class:`~django.http.SimpleCookie`.
1230 
1231-        * The :func:`~django.views.decorators.csrf.csrf_response_exempt` and
1232-          :func:`~django.views.decorators.csrf.csrf_view_exempt` decorators will
1233-          be removed. Since 1.4 ``csrf_response_exempt`` has been a no-op (it
1234-          returns the same function), and ``csrf_view_exempt`` has been a
1235-          synonym for ``django.views.decorators.csrf.csrf_exempt``, which should
1236-          be used to replace it.
1237+    * :class:`django.core.context_processors.PermWrapper` and
1238+      :class:`django.core.context_processors.PermLookupDict`
1239+      will be moved to :class:`django.contrib.auth.context_processors.PermWrapper`
1240+      and :class:`django.contrib.auth.context_processors.PermLookupDict`,
1241+      respectively.
1242 
1243-        * The :class:`~django.core.cache.backends.memcached.CacheClass` backend
1244-          was split into two in Django 1.3 in order to introduce support for
1245-          PyLibMC. The historical :class:`~django.core.cache.backends.memcached.CacheClass`
1246-          is now an alias for :class:`~django.core.cache.backends.memcached.MemcachedCache`.
1247-          In Django 1.6, the historical alias will be removed.
1248+    * The :setting:`MEDIA_URL` or :setting:`STATIC_URL` settings are
1249+      required to end with a trailing slash to ensure there is a consistent
1250+      way to combine paths in templates.
1251 
1252-        * The UK-prefixed objects of ``django.contrib.localflavor.uk`` will only
1253-          be accessible through their new GB-prefixed names (GB is the correct
1254-          ISO 3166 code for United Kingdom). They have been deprecated since the
1255-          1.4 release.
1256+1.6
1257+---
1258 
1259-        * The :setting:`IGNORABLE_404_STARTS` and :setting:`IGNORABLE_404_ENDS`
1260-          settings have been superseded by :setting:`IGNORABLE_404_URLS` in
1261-          the 1.4 release. They will be removed.
1262+    * The compatibility modules ``django.utils.copycompat`` and
1263+      ``django.utils.hashcompat`` as well as the functions
1264+      ``django.utils.itercompat.all`` and ``django.utils.itercompat.any``
1265+      have been deprecated since the 1.4 release. The native versions
1266+      should be used instead.
1267 
1268-        * The :doc:`form wizard </ref/contrib/formtools/form-wizard>` has been
1269-          refactored to use class based views with pluggable backends in 1.4.
1270-          The previous implementation will be deprecated.
1271+    * The :func:`~django.views.decorators.csrf.csrf_response_exempt` and
1272+      :func:`~django.views.decorators.csrf.csrf_view_exempt` decorators will
1273+      be removed. Since 1.4 ``csrf_response_exempt`` has been a no-op (it
1274+      returns the same function), and ``csrf_view_exempt`` has been a
1275+      synonym for ``django.views.decorators.csrf.csrf_exempt``, which should
1276+      be used to replace it.
1277 
1278-        * Legacy ways of calling
1279-          :func:`~django.views.decorators.cache.cache_page` will be removed.
1280+    * The :class:`~django.core.cache.backends.memcached.CacheClass` backend
1281+      was split into two in Django 1.3 in order to introduce support for
1282+      PyLibMC. The historical :class:`~django.core.cache.backends.memcached.CacheClass`
1283+      is now an alias for :class:`~django.core.cache.backends.memcached.MemcachedCache`.
1284+      In Django 1.6, the historical alias will be removed.
1285 
1286-        * The backward-compatibility shim to automatically add a debug-false
1287-          filter to the ``'mail_admins'`` logging handler will be removed. The
1288-          :setting:`LOGGING` setting should include this filter explicitly if
1289-          it is desired.
1290+    * The UK-prefixed objects of ``django.contrib.localflavor.uk`` will only
1291+      be accessible through their new GB-prefixed names (GB is the correct
1292+      ISO 3166 code for United Kingdom). They have been deprecated since the
1293+      1.4 release.
1294 
1295-        * The template tag
1296-          :func:`django.contrib.admin.templatetags.adminmedia.admin_media_prefix`
1297-          was deprecated since Django 1.4 and will be removed in favor of the
1298-          generic static files handling.
1299+    * The :setting:`IGNORABLE_404_STARTS` and :setting:`IGNORABLE_404_ENDS`
1300+      settings have been superseded by :setting:`IGNORABLE_404_URLS` in
1301+      the 1.4 release. They will be removed.
1302 
1303-        * The builin truncation functions
1304-          :func:`django.utils.text.truncate_words` and
1305-          :func:`django.utils.text.truncate_html_words`
1306-          were deprecated since Django 1.4 and will be removed in favor
1307-          of the ``django.utils.text.Truncator`` class.
1308+    * The :doc:`form wizard </ref/contrib/formtools/form-wizard>` has been
1309+      refactored to use class based views with pluggable backends in 1.4.
1310+      The previous implementation will be deprecated.
1311 
1312-    * 2.0
1313-        * ``django.views.defaults.shortcut()``. This function has been moved
1314-          to ``django.contrib.contenttypes.views.shortcut()`` as part of the
1315-          goal of removing all ``django.contrib`` references from the core
1316-          Django codebase. The old shortcut will be removed in the 2.0
1317-          release.
1318+    * Legacy ways of calling
1319+      :func:`~django.views.decorators.cache.cache_page` will be removed.
1320+
1321+    * The backward-compatibility shim to automatically add a debug-false
1322+      filter to the ``'mail_admins'`` logging handler will be removed. The
1323+      :setting:`LOGGING` setting should include this filter explicitly if
1324+      it is desired.
1325+
1326+    * The template tag
1327+      :func:`django.contrib.admin.templatetags.adminmedia.admin_media_prefix`
1328+      was deprecated since Django 1.4 and will be removed in favor of the
1329+      generic static files handling.
1330+
1331+    * The builin truncation functions
1332+      :func:`django.utils.text.truncate_words` and
1333+      :func:`django.utils.text.truncate_html_words`
1334+      were deprecated since Django 1.4 and will be removed in favor
1335+      of the ``django.utils.text.Truncator`` class.
1336+
1337+2.0
1338+---
1339+
1340+    * ``django.views.defaults.shortcut()``. This function has been moved
1341+      to ``django.contrib.contenttypes.views.shortcut()`` as part of the
1342+      goal of removing all ``django.contrib`` references from the core
1343+      Django codebase. The old shortcut will be removed in the 2.0
1344+      release.