On Wed, 03 Oct 2012 18:02:03 +0200, Larry Hastings <la...@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.) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com