[Python-Dev] Code freeze?

[Stephen J. Turnbull]

Not speaking for Barry or anyone else but myself.  This is an
explanation of how I understand the process and why I welcome it.

Scott Dial writes:

 > I don't understand who these alpha releases are supposed to be for, and 
 > who they will serve.

An alpha test is internal.  It is comprised of those tests the
developers working on the product (and/or an affiliated QA department)
can imagine.

Similarly, an alpha release is of, by, and for the developers.

 > I'm not sure what developer outside of the core community would
 > want to work with something missing key features and released
 > fairly arbitrarily.

Developers outside of the core community are not targeted.  That said,
how do you know that key features are missing?  Part of the point of a
release is that it says "*this stuff* is working".  I want *my* key
feature to be part of "this stuff", not *your* key feature.  Given "my
feature," I download to give the team feedback as early as possible.
Lacking yours, you don't.  Next alpha, presumably our roles will be
reversed.

 > More to the point, I don't know why a developer wouldn't just checkout 
 > from SVN in any case. Certainly if they are going to help root out bugs, 
 > then we would like them to be using the trunk if possible. I fear that 
 > once an alpha is 2 weeks old, we will start saying "please check if its 
 > still a problem on the trunk."

Software development in practice is a matter of "take two steps back,
then three steps forward."  The point of an alpha release is to
checkpoint what is a regression, and what is a temporary "feature"
introduced by new development.  The latter is admissible on the trunk,
but the goal should be none from one alpha to the next.  In other
words, a bug introduced by new development should be fixed by the next
alpha.  If it can't be, the developer misjudged the timing of the
merge to mainline; it wasn't ready yet.

 > A mild concern is how this effects checkins with individuals either 
 > trying to meet a deadline or even wait until after an alpha release to 
 > checkin a large change. I'm not sure this will happen, but having 
 > releases scheduled without feature milestones attached certainly changes 
 > the environment for work to be done in.

Scheduling feature milestones assumes that people put priority on
those features at a given time.  Barry can't assume that yet.  Once
the rhythm is established, Barry can start asking for, and some people
will start volunteering, milestone commitments for given releases.

I think that it probably is desirable to to put that deadline pressure
on.  Individuals who rush to get their work in, and cause alpha-to-
alpha regressions, can be advised to wait in the future in similar
circumstances.  Once the rhythm is established, people can expect that
alphas will be consistently increasing in features and consistently
decreasing in defects.  If that's not true, something's wrong with the
process, and the team needs to step back and do something about it.

But in the nature of software development, *monotone improvement is
not something you want to, or even can, impose on the trunk at all
points in time*.