Re: ATTENTION! Releasing Python 2.2.2 in a few weeks
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.
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 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. 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 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/)
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. Laura Creighton
[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/)
participants (2)
-
Guido van Rossum
-
Laura Creighton