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

[Guido van Rossum]

[Laura]
> 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.

Yes, but for 2.2.2 (and in general for maintenance branches) I would
never try to do any global idiom changes.  Those are only for the
trunk (and even then I usually frown upon them -- in our experience
here, these usually introduce a few bugs in rarely-used code that
don't get found out until 6-12 months mater).

> 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.

OTOH I don't want this to generate tons of messages to python-dev with
little more content than announcements that C is going to look at
module Y.

> 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.

And then you still need to decide whether you want that bug fixed in
2.2.  How thoroughly fixed does 2.2 need to be?

> > 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.

I very much doubt that anything would have crept into 2.2 cvs that we
don't want.  Or are you talking from the PBF POV and could they be
more conservative for Py-tie than we've been with 2.2.2?

> > 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.
> 
> 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.

I meant "why stop procrastinating". :-)

The ~two-week period was chosen to give people enough notice but not
be so far in the future that procrastinators will say to themselves
"I'll think about it closer to the release."  Two weeks seems just
about right based on my experience in this group.

> 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.

Halfway through with what?  I would expect that checkins would be
complete sets.  And if someone just *has* to check in stuff that
requires some more work, they should let us know so we can hold up the
release for them or make it a priority to fix it (by backing out or
finishing those changes).  Given the nature of most changes that need
to be backported this is unlikely -- almost all of them are small
fixes to one file.

> > 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.

Can you tell us more here about the Py-tie plans?  I know nothing
about it except that it'll be based on Python 2.2; I think it would be
helpful for the developer community to know what the long-term Py-tie
plans are.

> > 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).
> 
> 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.

You're welcome.  (At times I've wanted an addition to logmerge that
would restrict it to a certain branch; but I've not wanted it enough
to implement it.  I think you'd have to mine the "tags" output from
cvs log for each file to know the branch point and then act
accordingly for the revisions of that file.)

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