> 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. 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. > 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. 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. > 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. 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4