[Python-Dev] Python 3.4: Cherry-picking into rc2 and final

[Stephen J. Turnbull]

Nick Coghlan writes:

 > I suspect everyone is also highly aware of the fact that there are
 > some ambitious changes in 3.4,

Which is an argument for longer beta and RC periods than usual, or
maybe some of the ambition should have been restrained.  It's not
necessarily a reason why more eyes help (see below).

 > the release of rc1 is bringing the usual wave of additional third
 > party testing that has picked up some interesting regressions and
 > usability issues (e.g. the Alembic test suite found a fun one in
 > the inspect module, while the pip installation doesn't currently
 > play nice with UAC on Windows), and the Ubuntu 14.04 deadline
 > restricts our ability to add a 3rd rc.

OK, but that means we're screwed regardless.  We've decided to release
what we've got on a specific timeline, and a few extra days of testing
is going to make a marginal difference on average.

Remember that under time pressure in bugfixing, the average programmer
introduces a new bug that gets through to a product every ten lines.
OK, so we're[1] 100X better than average, and I suppose for some
subset 1000X better.  Still that means several new bugs, and some of
them may be doozies.

 > That brings with it a strong desire to parallelise things as much
 > as possible, and read only access to the upcoming release helps
 > greatly in knowing which regressions have already been addressed,
 > allowing third party testers to more easily focus on any remaining
 > issues.

Sure, but it *doesn't* help in knowing which ones are *correctly*
addressed.  These *are* ambitious changes; some of the remaining bugs
may be very deep.  The obvious fixes may do more harm than good.  Ie,
"more eyes" is (a) mostly a fallacy (as Heinlein put it, the wisdom of
a group is less than or equal to the maximum of the wisdom of the
members) and (b) in any case the "more eyes" effect is diluted if
people are deliberately looking at different parts of the code.

 > A "user beware, this may be rebased without warning" clone would be
 > fine for that purpose, and I suspect in most cases just running rc2
 > -> final with such a clone available (preserving Larry's current
 > workflow until rc2) would be sufficient to address most concerns.

Larry's already providing tarballs as I understand it.

The argument that a "read-only, no cherrypicking by committers" repo
is nothing but a better tarball is valid, but as I say, AFAICS the
expected gain is pretty marginal.  The conflict here is not Larry's
process, it's the decision to make an ambitious release on a short
time schedule.  I sympathize with Ubuntu to some extent -- they have a
business to run, after all.  But should Ubuntu desires be distorting a
volunteer RE's process?  Was Larry told that commercial interests
should be respected in designing his process?


Footnotes: 
[1]  FVO "we" not containing "me".  You'll notice I'm not submitting
patches.<wink/>