Martin, while I completely agree with you in principle, in practice this isn't possible. When the release branch is made there's usually a flurry of minor fixes, and these are almost guaranteed to break something on the mac. Tiny things, like missing casts, but breaks nonetheless. Moreover, the "release loop" is now about 24 hours long, according to PEP101, and even extending it seriously (like to about a week) still wouldn't guarantee that I could react timely. Not only am I 6 hours away from the unix/win release folks, but I also have a paying job that is less and less MacPython-related, so I can't firmly commit myself. And it has happened to me already (twice, I think) that there was a showstopper bug on the Mac that has caused me to either be very late with a release or skip one altogether. This happens on the Mac more often than on Unix/Windows, because MacPython relies on a third party unix I/O emulation library. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm
While this may happen in principle, and out of curiosity: Was this a problem in 2.2b1 also? Looking at the changes made on the 2.2b1 release branch, I see that a total of 7 files was changed. Except for patchlevel.h, and the \n\ fix on socketmodule.c, there were no changes to C code. So I can't see why the changes on the release branch could have any effect on the Mac port, atleast in this release.
I'm not asking that you work harder on Python, I'm asking that you work less :-) Seriously, I think there is a much larger set of people testing the CVS regularly, so I doubt any breakage atleast on OS X wouldn't be noticed within hours.
I sympathize with this problem, and I can't really suggest a good solution to it. I'm also not so much concerned about concerned about beta releases; nobody will care whether they can build 2.2b1 from the sources on the Mac two months from now. It's just that I think very strict principles must be applied for the final release. If that means that the 2.2 release can't go without ok from you (or somebody else who has produced MacOS 9 binaries), I think we should add that to the release procedure. That check would be to avoid show-stopper bugs only, of course - anything complex needs to be detected long before the final release. Regards, Martin
What's more common is actually a flurry of checkins just *before* the release branch is made (say in the last two days). These often include a somewhat hasty commit of a project that's valuable to have but introduces new bugs -- either Mac-specific or generic. The patch that introduced the missing \n\ problem was an example of this. I don't know what to do about this. Branching several days earlier doesn't prevent it, because usually there's a really good reason to copy the last-minute changes into the release branch. (We don't have the problem that some other projects appear to have, which is that there's a lot of tentative development on the trunk -- then it would make sense to branch earlier, but we tend to use the patch manager for experiments.)
I think that for the final release we should definitely attempt this. Hopefully the speed and quality of change will reduce closer to the final release. Also, the release candidate should help. Jack, We'll try to work with you. Barry, please add something to this effect in the release procedure PEP (hold up the *final* release until Jack approves or until we lose patience). --Guido van Rossum (home page: http://www.python.org/~guido/)
"GvR" == Guido van Rossum <guido@python.org> writes:
GvR> I think that for the final release we should definitely GvR> attempt this. Hopefully the speed and quality of change will GvR> reduce closer to the final release. Also, the release GvR> candidate should help. GvR> Jack, We'll try to work with you. Barry, please add GvR> something to this effect in the release procedure PEP (hold GvR> up the *final* release until Jack approves or until we lose GvR> patience). Absolutely. And done. -Barry
While this may happen in principle, and out of curiosity: Was this a problem in 2.2b1 also? Looking at the changes made on the 2.2b1 release branch, I see that a total of 7 files was changed. Except for patchlevel.h, and the \n\ fix on socketmodule.c, there were no changes to C code. So I can't see why the changes on the release branch could have any effect on the Mac port, atleast in this release.
I'm not asking that you work harder on Python, I'm asking that you work less :-) Seriously, I think there is a much larger set of people testing the CVS regularly, so I doubt any breakage atleast on OS X wouldn't be noticed within hours.
I sympathize with this problem, and I can't really suggest a good solution to it. I'm also not so much concerned about concerned about beta releases; nobody will care whether they can build 2.2b1 from the sources on the Mac two months from now. It's just that I think very strict principles must be applied for the final release. If that means that the 2.2 release can't go without ok from you (or somebody else who has produced MacOS 9 binaries), I think we should add that to the release procedure. That check would be to avoid show-stopper bugs only, of course - anything complex needs to be detected long before the final release. Regards, Martin
What's more common is actually a flurry of checkins just *before* the release branch is made (say in the last two days). These often include a somewhat hasty commit of a project that's valuable to have but introduces new bugs -- either Mac-specific or generic. The patch that introduced the missing \n\ problem was an example of this. I don't know what to do about this. Branching several days earlier doesn't prevent it, because usually there's a really good reason to copy the last-minute changes into the release branch. (We don't have the problem that some other projects appear to have, which is that there's a lot of tentative development on the trunk -- then it would make sense to branch earlier, but we tend to use the patch manager for experiments.)
I think that for the final release we should definitely attempt this. Hopefully the speed and quality of change will reduce closer to the final release. Also, the release candidate should help. Jack, We'll try to work with you. Barry, please add something to this effect in the release procedure PEP (hold up the *final* release until Jack approves or until we lose patience). --Guido van Rossum (home page: http://www.python.org/~guido/)
"GvR" == Guido van Rossum <guido@python.org> writes:
GvR> I think that for the final release we should definitely GvR> attempt this. Hopefully the speed and quality of change will GvR> reduce closer to the final release. Also, the release GvR> candidate should help. GvR> Jack, We'll try to work with you. Barry, please add GvR> something to this effect in the release procedure PEP (hold GvR> up the *final* release until Jack approves or until we lose GvR> patience). Absolutely. And done. -Barry
participants (4)
-
barry＠zope.com -
Guido van Rossum -
Jack Jansen -
Martin v. Loewis