[Python-Dev] PEP 407: New release cycle and introducing long-term support versions

[Stephen J. Turnbull]

Georg Brandl writes:

 > "The status quo really isn't all that bad" applies to any PEP.  Also,
 > compared to most PEPs, it is quite easy to revert to the previous
 > state of things if they don't work out as wanted.

That depends on how "doesn't work out" plays out.  If meeting the
schedule *and* producing a good release regularly is just more work
than expected, of course you're right.

If you stick to the schedule with insufficient resources, and lack of
testing produces a really bad release (or worse, a couple of sorta bad
releases in succession), reverting Python's reputation for stability
is going to be non-trivial.

 > a) The release manager's job is not as bad as you might believe.  We
 > have an incredibly helpful and active core of developers which means
 > that the RM job is more or less "reduced" to pronouncing on changes
 > during the rc phase, and actually producing the releases.

I've done release management and I've been watching Python do release
management since PEP 263; I'm well aware that Python has a truly
excellent process in place, and I regularly recommend studying to
friends interested in improving their own projects' processes.

But I've also (twice) been involved (as RM) in a major revision of RM
procedures, and both times it was a lot more work than anybody
expected.  Finally, the whole point of this exercise is to integrate a
lot more stdlib changes (including whole packages) than in the past on
a much shorter timeline, and to do it repeatedly.  "Every six months"
still sounds like a long time if you are a "leaf" project still
working on your changes on your own schedule and chafing at the bit
waiting to get them in to the core project's releases, but it's
actually quite short for the RM.

I'm not against this change (especially since, as Antoine so
graciously pointed out, I'm not going to be actually doing the work in
the foreseeable future), but I do advise that the effort required
seemed to be dramatically underestimated.

 > b) I did not have the impression (maybe someone can underline that
 > with tracker stats?) that there were a lot more bug reports than
 > usual during the alpha and early beta stages of Python 3.2.

Yeah, but the question for Python's stability reputation is "were
there more than zero?"  Every bug that gets through is a risk.