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.
Christian
_______________________________________________
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
