-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Aug 14, 2008, at 10:33 AM, Christian Heimes wrote:
By the way the guys are totally awesome, dude. :)
I agree wholeheartedly!
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.
That wouldn't have helped. multiprocessing was added during the alpha
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.
If we did this, I think it should be less than 18 months between
releases. But I also fear that there will be too much pressure to add
new features anyway.
I remember at some distant Python conference, Guido asked the
audience, how many people feel Python is changing too fast, and then
how many people feel it's missing an important feature. IIRC, the
show of hands was about equal.