Edited release-process.txt changes from [17300]

git-svn-id: http://code.djangoproject.com/svn/django/trunk@17310 bcc190cf-cafb-0310-a4f2-bffc1f526a37

1 files changed, 7 insertions, 7 deletions

diff --git a/docs/internals/release-process.txt b/docs/internals/release-process.txt
index e82bdc2c4c..8ead4d7ae7 100644
--- a/docs/internals/release-process.txt
+++ b/docs/internals/release-process.txt
@@ -111,12 +111,12 @@ varying levels:
 * Security fixes will be applied to the current trunk and the previous two
   minor releases.
 
-* Documentation fixes will generally be more freely backported to the last
-  release branch (at the discretion of the committer), and don't need to meet
-  the "critical fixes only" bar as it's highly advantageous to have the docs
-  for the last release be up-to-date and correct, and the downside of
-  backporting (risk of introducing regressions) is much less of a concern
-  with doc fixes.
+* Documentation fixes generally will be more freely backported to the last
+  release branch, at the discretion of the committer, and they don't need to
+  meet the "critical fixes only" bar. That's because it's highly advantageous
+  to have the docs for the last release be up-to-date and correct, and the
+  downside of backporting (risk of introducing regressions) is much less of a
+  concern.
 
 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:
@@ -130,7 +130,7 @@ Django 1.3 and 1.4. At this point in time:
   ``1.2.X`` branch. They will trigger the release of ``1.3.1``, ``1.2.1``,
   etc.
 
-* Documentation fixes will be applied to trunk, and if easily backported, to
+* Documentation fixes will be applied to trunk, and, if easily backported, to
   the ``1.3.X`` branch.
 
 .. _release-process: