updates

pep-0101.txt

@@ -17,9 +17,9 @@ Abstract
     buddies firmly attached to your bare back, anchored by newly sharpened
     claws.  At least they're cute, you remind yourself.
 
-    Actually, no that's a slight <wink> exaggeration.  The Python release
+    Actually, no that's a slight exaggeration <wink>.  The Python release
     process has steadily improved over the years and now, with the help of our
-    amazing community, is really not to difficult.  This PEP attempts to
+    amazing community, is really not too difficult.  This PEP attempts to
     collect, in one place, all the steps needed to make a Python release.  It
     is organized as a recipe and you can actually print this out and check
     items off as you complete them.
@@ -38,7 +38,6 @@ How to Make A Release
         * RM = Release Manager: Barry Warsaw
         * WE = Windows: Martin von Loewis
         * ME = Mac: Ronald Oussoren
-        * DE = Documentation: Fred Drake
 
     XXX: We should include a dependency graph to illustrate the steps
     that can be taken in parallel, or those that depend on other
@@ -64,13 +63,12 @@ How to Make A Release
     This helps by performing several automatic editing steps, and guides you
     to perform some manual editing steps.
 
-  ___ Impose a check-in freeze.  Send a message to these mailing lists:
+  ___ Log into irc.freenode.net and join the #python-dev channel.
-      * python-committers@python.org
-      * python-dev@python.org
-      * (Py3: python-3000@python.org)
 
-      telling people not to make any check-ins on the tree until further
+      You probably need to coordinate with other people around the
-      notice.
+      world.  This IRC channel is where we've arranged to meet.
+
+  ___ Impose a check-in freeze by sending email to python-committers@python.org
 
       At this point, nobody except the RM or his duly assigned agents should
       make any commits to the branches.  The assigned agents are either from
@@ -82,11 +80,6 @@ How to Make A Release
 
       The RM has full authority to revert any unapproved commits.
 
-  ___ Log into irc.freenode.net and join the #python-dev channel.
-
-      You probably need to coordinate with other people around the
-      world.  This IRC channel is where we've arranged to meet.
-
   ___ Check to see if there are any showstopper bugs.
 
       Go to http://bugs.python.org and look for any open bugs that can block
@@ -94,15 +87,21 @@ How to Make A Release
       release you're making; here are the relevant definitions:
 
       release blocker - Stops the release dead in its tracks.  You may not
-        make a release with any open blocker bugs.
+                        make a release with any open blocker bugs.
 
-      critical - Important bugs that may become blockers for the next
+      deferred blocker - Doesn't block this release, but it will block a
-        release.  You can make alpha and beta releases with open critical
+                         future release.
-        bugs, but you may not make a final release with open critical bugs.
+
+      critical - Important bugs that should be fixed before the next release,
+                 but which won't block a non-final release.
+
+      You can make alpha and beta releases with open critical bugs, but you
+      may not make a final release with open critical bugs.
 
       Review the release blockers and either resolve them, bump them down to
-      critical, or stop the release and ask for community assistance.  If
+      deferred, or stop the release and ask for community assistance.  If
-      you're making a final release, do the same with any open crticial bugs.
+      you're making a final release, do the same with any open deferred and
+      crticial bugs.
 
   ___ Check the stable buildbots.
 
@@ -136,8 +135,7 @@ How to Make A Release
       ___ The LICENSE file.  Add the pending version to the list of releases,
           and be sure to check the release dates. 
 
-      ___ There's a copy of the license in Doc/license.rst; the DE usually
+      ___ There's a copy of the license in Doc/license.rst
-          takes care of that, but it's good to double check this.
 
       ___ Doc/tutorial/interpreter.rst (3 references to '[Pp]ython26', one
           to 'Python 2.6').
@@ -205,97 +203,6 @@ How to Make A Release
   ___ XXX If this is a release candidate, mail Sean <jafo@tummy.com>
       noting the impending release, so that RPMs can be built and tested.
 
-  ___ XXX At this point, the DE will create the formatted versions of the
-      documentation and push the appropriate files out to their FTP
-      locations on www.python.org.  The HTML format is used to build
-      the HTML Help format for the Windows installer, but the RM
-      doesn't need this to build the source distribution.  The HTML
-      Help format will typically be generated by whoever builds the
-      Windows installer.
-
-      Once the DE is done, there can be no further checkins on the
-      branch in the Doc/ directory -- not even by the RM.
-
-      Building the documentation is done using the Makefile in the
-      Doc/ directory.  Use these commands to build the formatted
-      documentation packages:
-
-        $ make clean
-        $ make distribution
-
-      The packages in build/distribution can be installed on the
-      FTP server using commands like these:
-
-        $ VERSION=`python tools/sphinxext/patchlevel.py`
-        $ TARGET=/data/python-releases/doc/$VERSION
-        $ ssh dinsdale.python.org mkdir $TARGET
-        $ scp build/distribution/* dinsdale.python.org:$TARGET
-
-  ___ XXX For final releases, publish the documentation on python.org.
-      This must be done by someone with write access to the pydotorg
-      repository.
-
-      Start by creating a new directory and filling it with the
-      standard boilerplate.  $VERSION is the same as for uploading the
-      documentation, above; $OLDVERSION is the most recently published
-      version on the site.
-
-        $ cd .../pydotorg/doc/
-        $ svn mkdir $VERSION $VERSION/download
-        $ cd $OLDVERSION
-        $ svn cp content.{html,rst,yml} index.yml nav.yml ../$VERSION
-        $ cd download
-        $ svn cp content.{html,rst,yml} index.yml nav.yml ../$VERSION/download
-        $ cd ../../$VERSION
-
-      In $VERSION/content.rst and $VERSION/download/content.rst, change:
-
-      - in the header at the top of the page, update to reflect
-        the version number and release date
-      - if the minor release number changed (for example, from 2.5
-        to 2.6), the title and link to the "What's New" document
-        (search for "whatsnew")
-      - make sure all the documents included in the package are listed
-
-      In $VERSION/index.yml and $VERSION/download/index.yml, change
-      the version number in the title.
-
-      In versions/content.rst, add an entry for the new version near
-      the top.
-
-      Use the "rst2html" command (commonly installed with docutils) to
-      ensure that the .rst files can be formatted without errors.
-
-      Log into dinsdale.python.org using SSH and unpack a copy of the
-      documentation into place:
-
-        # on dinsdale:
-        $ cd /data/ftp.python.org/pub/www.python.org/doc
-        $ bzip2 -dc /data/python-releases/doc/$VERSION/html-$VERSION.tar.bz2 \
-          | tar xf -
-        $ mv Python-Docs-$VERSION $VERSION
-        $ find $VERSION -type d | xargs chmod g+s
-
-      Now head back to your pydotorg checkout and commit the changes
-      so the site will be updated:
-
-        $ svn commit -m \
-          "Add website content for Python $VERSION documentation."
-
-      Point your browser at this URL and check it out:
-
-        http://www.python.org/doc/$VERSION/
-
-      There is one more change that may need to happen in the
-      top-level doc/ directory of the website content.  This should
-      happen as soon as the release announcement has been made.  The
-      required actions are described in a separate step of this
-      checklist.
-
-  ___ XXX Ping Neal Norwitz (or anyone else with access to the PSF box
-      which runs the automated builds) to fix conflicts that arise
-      in the checked out working areas.
-
   ___ XXX The WE builds the Windows helpfile, using (in Doc/) either
 
         $ make htmlhelp   (on Unix)