[Python-checkins] r66421 - peps/trunk/pep-0101.txt
barry.warsaw
python-checkins at python.org
Sat Sep 13 02:22:57 CEST 2008
Author: barry.warsaw
Date: Sat Sep 13 02:22:56 2008
New Revision: 66421
Log:
updates
Modified:
peps/trunk/pep-0101.txt
Modified: peps/trunk/pep-0101.txt
==============================================================================
--- peps/trunk/pep-0101.txt (original)
+++ peps/trunk/pep-0101.txt Sat Sep 13 02:22:56 2008
@@ -17,9 +17,9 @@
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 @@
* 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 @@
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:
- * python-committers at python.org
- * python-dev at python.org
- * (Py3: python-3000 at python.org)
+ ___ Log into irc.freenode.net and join the #python-dev channel.
- telling people not to make any check-ins on the tree until further
- notice.
+ You probably need to coordinate with other people around the
+ world. This IRC channel is where we've arranged to meet.
+
+ ___ Impose a check-in freeze by sending email to python-committers at 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 @@
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 @@
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
- release. You can make alpha and beta releases with open critical
- bugs, but you may not make a final release with open critical bugs.
+ deferred blocker - Doesn't block this release, but it will block a
+ future release.
+
+ 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
- you're making a final release, do the same with any open crticial bugs.
+ deferred, or stop the release and ask for community assistance. If
+ you're making a final release, do the same with any open deferred and
+ crticial bugs.
___ Check the stable buildbots.
@@ -136,8 +135,7 @@
___ 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
- takes care of that, but it's good to double check this.
+ ___ There's a copy of the license in Doc/license.rst
___ Doc/tutorial/interpreter.rst (3 references to '[Pp]ython26', one
to 'Python 2.6').
@@ -205,97 +203,6 @@
___ XXX If this is a release candidate, mail Sean <jafo at 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)
More information about the Python-checkins
mailing list