Rev 6015: More tweaks and typo fixes. in file:///home/vila/src/bzr/releases/work/

[Vincent Ladeuil]

At file:///home/vila/src/bzr/releases/work/

------------------------------------------------------------
revno: 6015
revision-id: v.ladeuil+lp at free.fr-20110719071349-trwpg0h6pzcq5b73
parent: v.ladeuil+lp at free.fr-20110718161026-gpr8wlw05osfztap
committer: Vincent Ladeuil <v.ladeuil+lp at free.fr>
branch nick: work
timestamp: Tue 2011-07-19 09:13:49 +0200
message:
  More tweaks and typo fixes.
-------------- next part --------------
=== modified file 'doc/developers/releasing.txt'
--- a/doc/developers/releasing.txt	2011-07-18 16:10:26 +0000
+++ b/doc/developers/releasing.txt	2011-07-19 07:13:49 +0000
@@ -187,9 +187,9 @@
 
 #. Update the "What's New" documents in ``doc/en/whats-new``.
 
-#. Make sure a milestone exists for your release and that is it active,
-   <https://launchpad.net/bzr/x.y> will list the existing milestones,
-   <https://launchpad.net/bzr/x.y/x.y.z/+edit> will allow you to toggle the
+#. Make sure a milestone exists for your release and that it is active,
+   <https://launchpad.net/bzr/x.y> lists the existing milestones,
+   <https://launchpad.net/bzr/x.y/x.y.z/+edit> allows you to toggle the
    active flag.
 
 #. Commit this and send it to PQM.
@@ -388,10 +388,10 @@
 they do, they either targeted the wrong branch or didn't update the news
 file correctly, so the sooner the branch is opened again, the better.
 
-This matter more for ``lp:bzr`` than for ``lp:bzr/x.y``, ``lp:bzr`` should
+This matters more for ``lp:bzr`` than for ``lp:bzr/x.y``, ``lp:bzr`` should
 always be open for landing, so you should do `At the start of a release
 cycle`_ as soon as possible (i.e. update the verion number in ``bzr`` and
-``bzrlib/__init__``, update/create the news files and create/update the
+``bzrlib/__init__``, create/update the news files and create/update the
 milestone for the next relase).
 
 You may also need to do `At the start of a series cycle`_ if you're starting
@@ -402,14 +402,15 @@
 the *last* beta for a given ``x.y`` series (from trunk aka lp:bzr), you need
 to setup *two* branches for the next cycle:
 
-#. ``lp:bzr`` needs to be opened for the *next* series ``x.(y+1)``
+#. ``lp:bzr`` needs to be opened for the next *series* ``x.(y+1)``
 
-#. ``lp:bzr/x.y`` needs to be opened for the next release ``x.y.0``. Since
-   this is first real use of ``lp:bzr/x.y``, this is also the deadline for the
-   PQM branch to be created.
+#. ``lp:bzr/x.y`` needs to be opened for the next *release* ``x.y.0`` in the
+   series. Since this is first real use of ``lp:bzr/x.y``, this is also the
+   deadline for the PQM branch to be created.
 
 Both are important as ``lp:bzr`` should remain open so any change can be
-landed, ``lp:bzr/x.y`` should be ready to receive bug fixes.
+landed, ``lp:bzr/x.y`` on the other hand should be ready to receive bug
+fixes.
 
 ``lp:bzr`` is generally more important as the bug fixes on ``lp:bzr/x.y``
 won't be released sooner than a month from now whereas people may already
@@ -435,7 +436,7 @@
 There is normally a delay of a few days after the source freeze to allow
 for binaries to be built on various platforms.  Once they have been built,
 we have a releasable product.  The next step is to make it generally
-available to the world.
+available to the world.1
 
 #. Go to the release web page at <https://launchpad.net/bzr/x.y/x.y.z>
 
@@ -456,8 +457,9 @@
 
 #. Make an announcement mail.
 
-   For beta releases, this is sent to the ``bazaar`` list only to inform
-   plugin authors and package or installer managers.
+   For beta releases, this is sent to the ``bazaar at lists.canonical.com``
+   list only to inform plugin authors and people responsible for building
+   packages or installers.
 
    Once the installers are available, the mail can be sent to the
    ``bazaar-announce`` list too.