Barry Warsaw wrote:
Unfortunately, they're not being solved without PQM either! Really, we've had to delay releases several times because the branches were broken across multiple operating systems. Pleading on the mailing lists doesn't help. Hanging out on irc doesn't help. Having Benjamin, Georg, and others kicking ass on #python-dev the day of a release, is great, but it's also asking a lot of them.
Yeah, I concur with you. I've also done my fair share of nights dragging, kicking and punching the code into shape for a release. It sucks and it's sending my coffee bill sky high.
By the way the guys are totally awesome, dude. :)
That's what branches are for. I really strongly feel that the mainlines (by which I mean the branches we cut releases from) should always be in a releasable state. We should never be committing broken tests to these mainlines. If you spot a problem you can't fix, create a branch and commit the broken test there, and ask for help with that branch. The mainline isn't (IMHO) the place for that.
You're right that it will slow us down, but only on the mainline.
That's a good thing, especially if it buys you high quality.
Sticking to our own rules would also buy us quality ... Let's not add new features to our code base during the beta phase, please. Although the addition of multiprocessing had some merit, we shouldn't to the same mistake twice.
Perhaps we could adopt a release plan similar to Ubuntu. They have releases with cool, new and bleeding edge stuff followed by a release that focuses on stability and long term support. Python 2.6 and especially 3.0 are releases with new features. What do you think about focusing on stability and long time support for 2.7 and 3.1? 2.7 might be the last version of the 2.x series and we sure gonna have to fix lots of issues in the 3.x series until it's matured.