[Python-Dev] ATTENTION! Releasing Python 2.2.2 in a few weeks

Guido van Rossum guido@python.org
Fri, 20 Sep 2002 17:26:30 -0400


I'd like to release something called Python 2.2.2 in a few weeks (say,
around Oct 8; I like Tuesday release dates).

PythonLabs has no time to do a thorough search for all backport/bugfix
candidates in the trunk; if you want to help, the best thing you can
do is take your favorite set of modules or core files and
systematically backport anything that's clearly a bugfix and backports
easily.  Or you could simply make sure that your favorite bugfix is
backported.

I know Laura Creighton volunteered to help on behalf of the PBF, but I
don't know how long she'll take, and she can surely use help.  OTOH,
if nobody has time, I think it's fine to release what we have in CVS
on the 2.2 maintenance branch (the branch is named release22-maint).

Why release now?  It's been a while!  It'll be almost 6 months since
2.2.1 was released.  There have been a few important bugfixes (e.g. a
crash with ExtensionClasses on Solaris) that have bugged real-world
users.

Why release what we've got?  Frankly, I expect that nobody has the
time to backport everything that could reasonably be backported, so if
we wait for that to happen, we'll never have another release.  What
we've got is definitely a lot better than 2.2.1.

What about Python-in-a-tie?  Maybe Laura can shed light on the PBF's
schedule for that; I expect it'll be much longer in the making than
the planned 2.2.2 release.

What about Python 2.3?  Alpha by the end of 2002 is the best I can
promise.

What can you do?  Here's a brief treatise on backporting bugs that I
sent to Laura earlier:

    Basically, someone does the tedious part of triage, which means
    going over *every* 2.3 checkin message (with quick access to the
    corresponding diffs) and sorting them into:

    - already applied

    - trivial reject (e.g. new feature or fix for a bug introduced in
      2.3)

    - trivial accept (pure bugfix that applies cleanly to 2.2)

    - messy (e.g. unclear whether it's a bugfix or a feature even
      after staring at the source, bugfixes that affect binary
      compatibility, bugfixes that can only be applied with much code
      wrangling due to other changes in the code at the same place,
      etc.)

    Feel free to compile a list of "messy" ones and send it to
    python-dev.  It doesn't have to be all at once -- for big messy
    ones a separate python-dev discussion may be appropriate.

I think it's best not use the SF trackers to suggest bugs to be
backported -- this would merely be confusing, and it's a pretty heavy
communication mechanism.  If you want to help but don't have checkin
permission, find someone who does and work with them -- or we can give
you checkin permission (depending on your reputation).

--Guido van Rossum (home page: http://www.python.org/~guido/)