python2.1.2 plans, plus the curse of PEP-006.
Ok, after a bit of an unfortunate break I'm back into the backporting. My current plan is to have a release candidate for 2.1.2 due a couple of days before Christmas, and then try to get it tested as much as possible before a release either in the week between christmas/new year (not optimal) or shortly after. I'd hoped to get this stuff done much sooner, but unfortunately a combination of various personal matters has knocked me out for a couple of weeks. (I'm not sure if it's just me, but it's possible the reason no-one's done two bugfix releases in a row is that PEP-006 is accursed, and brings down the wrath of gods on anyone foolish enough to get involved. I'm hoping that the last few weeks horror is over and done now...) Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
Welcome back, Anthony! Glad to hear you haven't given up. If there's anything we can do to alleviate the curse, let us know... --Guido van Rossum (home page: http://www.python.org/~guido/)
"AB" == Anthony Baxter <anthony@interlink.com.au> writes:
AB> (I'm not sure if it's just me, but it's possible the reason AB> no-one's done two bugfix releases in a row is that PEP-006 is AB> accursed, and brings down the wrath of gods on anyone foolish AB> enough to get involved. I'm hoping that the last few weeks AB> horror is over and done now...) Anthony, First, thanks for taking on the responsibility, and glad you're back! Second, remember that PEP 6 is a work in progress, especially since you're breaking new ground. If PEP 6 actually hinders patch releases rather than helps them, then IMHO the PEP is probably broken. Is your problem with it the prohibitions? Or is it the procedure? Is the PEP too incomplete to be helpful? Please do suggest changes! If you want to co-own it so you can update it yourself, we can do that too. Patch releases should be easy(er). -Barry
I had a think about this, and I think the major issue is that there was quite a gap to backfill between 2.1.1 and me starting 2.1.2. There was a bit of backporting (thank you twouters!), but not that much - and not that much done as far as marking bugfixes in the changelogs. Given the rate of change in the python core, I'd say that it's more likely that people are going to want the ability to switch versions when it suits them, and thus keeping up the version before the current bleeding edge is appropriate. I'd say that something like the following would make life easier The branch for 2.N-maint should be maintained until 2.(N+1) gets a first patch release. That is, 2.1-maint gets bugfixes until 2.2.1 gets out the door. Alternately, waiting X months after 2.(N+1).0 would be another approach. In any case, marking bugfix candidates in CVS logs should be a standard thing to do. In terms of concrete things I'm looking for right now: . someone who's either a HP/UX victim^W user who's prepared to try and work out what bits need backporting for the threading fix, or someone who's got a HP/UX box and is prepared to let me ssh into the box and try and do it myself. . people to test the 2.1.2 release candidate when it's ready on a bunch of different platforms - I only have access to solaris, linux, and whatever's in the sf compile farm. Anthony
Anthony Baxter wrote:
What does "should be maintained" mean? With CVS, IIUC, there's no reason not to keep branches around forever. If instead what you're talking about is policy for work to be assigned, I won't let that into PEP6; the entire point of PEP6 is that it only prescribes procedure for someone who is already working, it does not specify any work to be accomplished in the abstract. The original form of PEP6 was looser in this respect (in terms of specifying when patch releases would occur and so on), but I was convinced by Guido et al to stick strictly to "how" and not "when" or "what". At the very least, I think we should stick with the current base plan for one or two more release cycles before making any structured attempts to integrate bugfixes into the standard Python release cycle.
In any case, marking bugfix candidates in CVS logs should be a standard thing to do.
The problem lies in creating the social structure to make that happen. People who monitor CVS need to get into the habit of reminding each other to mark bugfix candidates. But that's beyond the scope of PEP6. -- --- Aahz (@pobox.com) Hugs and backrubs -- I break Rule 6 <*> http://www.rahul.net/aahz/ Androgynous poly kinky vanilla queer het Pythonista We must not let the evil of a few trample the freedoms of the many.
Anthony Baxter wrote:
Hmmmm.... I think the fact that three different people have stepped up to the plate to handle bugfix releases is a *feature*. In addition, three releases in six months does not a long-term trend make. As Barry said, if there's a problem with PEP6, I'd love to know about it; other than that, there haven't IMO been enough Python releases and patches to warrant more bugfix releases than have occurred or are on the plate. Good work so far! -- --- Aahz (@pobox.com) Hugs and backrubs -- I break Rule 6 <*> http://www.rahul.net/aahz/ Androgynous poly kinky vanilla queer het Pythonista We must not let the evil of a few trample the freedoms of the many.
Welcome back, Anthony! Glad to hear you haven't given up. If there's anything we can do to alleviate the curse, let us know... --Guido van Rossum (home page: http://www.python.org/~guido/)
"AB" == Anthony Baxter <anthony@interlink.com.au> writes:
AB> (I'm not sure if it's just me, but it's possible the reason AB> no-one's done two bugfix releases in a row is that PEP-006 is AB> accursed, and brings down the wrath of gods on anyone foolish AB> enough to get involved. I'm hoping that the last few weeks AB> horror is over and done now...) Anthony, First, thanks for taking on the responsibility, and glad you're back! Second, remember that PEP 6 is a work in progress, especially since you're breaking new ground. If PEP 6 actually hinders patch releases rather than helps them, then IMHO the PEP is probably broken. Is your problem with it the prohibitions? Or is it the procedure? Is the PEP too incomplete to be helpful? Please do suggest changes! If you want to co-own it so you can update it yourself, we can do that too. Patch releases should be easy(er). -Barry
I had a think about this, and I think the major issue is that there was quite a gap to backfill between 2.1.1 and me starting 2.1.2. There was a bit of backporting (thank you twouters!), but not that much - and not that much done as far as marking bugfixes in the changelogs. Given the rate of change in the python core, I'd say that it's more likely that people are going to want the ability to switch versions when it suits them, and thus keeping up the version before the current bleeding edge is appropriate. I'd say that something like the following would make life easier The branch for 2.N-maint should be maintained until 2.(N+1) gets a first patch release. That is, 2.1-maint gets bugfixes until 2.2.1 gets out the door. Alternately, waiting X months after 2.(N+1).0 would be another approach. In any case, marking bugfix candidates in CVS logs should be a standard thing to do. In terms of concrete things I'm looking for right now: . someone who's either a HP/UX victim^W user who's prepared to try and work out what bits need backporting for the threading fix, or someone who's got a HP/UX box and is prepared to let me ssh into the box and try and do it myself. . people to test the 2.1.2 release candidate when it's ready on a bunch of different platforms - I only have access to solaris, linux, and whatever's in the sf compile farm. Anthony
Anthony Baxter wrote:
What does "should be maintained" mean? With CVS, IIUC, there's no reason not to keep branches around forever. If instead what you're talking about is policy for work to be assigned, I won't let that into PEP6; the entire point of PEP6 is that it only prescribes procedure for someone who is already working, it does not specify any work to be accomplished in the abstract. The original form of PEP6 was looser in this respect (in terms of specifying when patch releases would occur and so on), but I was convinced by Guido et al to stick strictly to "how" and not "when" or "what". At the very least, I think we should stick with the current base plan for one or two more release cycles before making any structured attempts to integrate bugfixes into the standard Python release cycle.
In any case, marking bugfix candidates in CVS logs should be a standard thing to do.
The problem lies in creating the social structure to make that happen. People who monitor CVS need to get into the habit of reminding each other to mark bugfix candidates. But that's beyond the scope of PEP6. -- --- Aahz (@pobox.com) Hugs and backrubs -- I break Rule 6 <*> http://www.rahul.net/aahz/ Androgynous poly kinky vanilla queer het Pythonista We must not let the evil of a few trample the freedoms of the many.
Anthony Baxter wrote:
Hmmmm.... I think the fact that three different people have stepped up to the plate to handle bugfix releases is a *feature*. In addition, three releases in six months does not a long-term trend make. As Barry said, if there's a problem with PEP6, I'd love to know about it; other than that, there haven't IMO been enough Python releases and patches to warrant more bugfix releases than have occurred or are on the plate. Good work so far! -- --- Aahz (@pobox.com) Hugs and backrubs -- I break Rule 6 <*> http://www.rahul.net/aahz/ Androgynous poly kinky vanilla queer het Pythonista We must not let the evil of a few trample the freedoms of the many.
participants (4)
-
aahz＠rahul.net -
Anthony Baxter -
barry＠zope.com -
Guido van Rossum