[Python-Dev] Proposed schedule for Python 3.4 (original) (raw)

R. David Murray rdmurray at bitdance.com
Wed Oct 3 18:26:49 CEST 2012

On Wed, 03 Oct 2012 18:02:03 +0200, Larry Hastings <larry at hastings.org> wrote:

Changing an existing alpha to be earlier doesn't alter the workload, but I fear it makes the alpha less relevant. Evaluating alphas / betas takes an investment of time, and whether or not a potential alpha user makes that investment depends on what they expect to get out of testing the alpha. If they're doing it out of the goodness of their hearts, just to help Python--well, that's fabulous, and more / earlier alphas might actually interest them. But my suspicion is that most people who try the alphas are doing early integration testing with their own stuff. For those people, the earlier the alpha, the less interesting it probably is to them. Earlier means that the software will be less finished. It will be buggier, it won't have as many features as the beta will. As a result it won't be as revealing--or as relevant--as a later alpha or even a beta. If that's their perspective, I suspect they'll be less likely to try an earlier alpha.

In my perception (again, I can't point to any raw data) there is an opposite dynamic that happens in stable projects that produce alphas throughout the release cycle. In those projects, people will often run the alphas, even in production[1], in order to get the new features sooner.

Python is a stable project. Even our alphas do not as a rule brown bag, though their suitability for specific projects depends on the bugs found.

I think Python could be in this camp, if we wanted to be.

(I'm not addressing release-team load here, I'm just making an observation.)

--David

[1] I am not advocating running an alpha in production, but for some projects "production" is a small enough audience that they can get away with it.)

More information about the Python-Dev mailing list