[Python-Dev] Re: ATTENTION! Releasing Python 2.2.2 in a few weeks
Mon, 23 Sep 2002 12:01:20 +0200
> 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
Ah, before you start systemetically backporting, make sure you
_announce_ that you are about to do this backporting. Otherwise you
will find that your favourite modules are also somebody else's
favourite modules and you have both wasted time and made the eventual
merge job harder. This is particularily true of people who need to
make a idiom change throughout the entire code base -- they will need
to modify files which aren't of any particular interest to you. If
somebody is in the middle of working on those files in particular when
you come through with your idiom change it is very easy for them to
overwrite your change, either because it happened in a different part of
the file, one that does not have their attention, or because
they did not notice that, in addition to the masive refactoring
which they got right as part of a backport, they also have to change
an idiom. This sort of thing drives release managers nuts.
Note: 'I mentioned it on the wiki someplace' is not good enough. Busy
people want to get their bugfixes out and in quickly, not participate
in a community or create content. Thus the loose structure of a wiki,
which is its strength in community building and in building
broad-based participation becomes its downfall when you actually want
to quickly know what you have to do, get in, and then get out. A page
where one lists such things seems a fine compromise, as long as everybody
is aware that some people won't be update, or update properly, anyway.
I've been reading the 2.2 cvs over the last week, trying to ge my
brain around which changes go with which bugs and which features. I
have found some patches where what I think happened is that in
addition to adding some feature, while somebody was there they
decided to fix a little unrelated ugliness at the same time. Now
the task is deciding if that ugliness is also a bug.
> 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).
I certainly can use help.
But given your current plan to release in a few weeks, I wonder if my
task might be better changed from tracing all the changes from the
last release to 2.2 maintenance, to starting from 2.2 maint and
seeing if there is something we _don't_ want in, which needs removing.
I still don't have a good enough perspective to judge this.
> 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
Ah, that doesn't exactly explain why now -- that is in a few weeks --
rather than in one months time, or even now, that is this morning.
The only problem I see on my end is if I decide to procede starting
with 2.2.2 as the base release for Python-in-a-Tie and then swarms
of people show up saying, well, actually I was half way through something
when 2.2.2 came out, so for PIT you have to either remove <all of this>
stuff or add <all of that>. Is now a quiet time, or do people expect
a lot of that to occur? There is nothing like announcing an impending
release to get a lot of code out from the woodwork -- so I guess we
will find out.
> 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.
It has to be, by definition. We need the Python for people to test their
extension modules against before we can package up the extension modules.
> What about Python 2.3? Alpha by the end of 2002 is the best I can
> 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
> - 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,
> 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/)
You also pointed me at Tools/scripts/logmerge.py , which I thought
I would mention in case anybody reading here isn't familiar with it.
It sorts the messages produced by cvs log by date and time, rather
than by file. really useful. Thank you.