Home Original page

[Python-Dev] Proposed schedule for Python 3.4

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