Re: 2 - Stable releases and roadmap (radical change)

[Trevor Daniels]

Graham Percival wrote Tuesday, June 26, 2012 9:55 PM

> *** Summary
> 
> Let’s drop the “any unintended change” thing, and go totally with
> the regression tests. Tests pass? We can make a stable release.
> Also, let’s have an official roadmap.

Rather than discussing each point separately below I prefer to
make some general observations.  The present proposal is too
detailed and not sufficiently radical.  We need to consider
wider options and consequences first, before honing the details.

1. So far there have been c. 75 critical regressions under the
current definition of 'critical' since 2.14.  All but one have been 
fixed, many of them promptly.  This prompt attention IMO
is due only to the fact that they were deemed to block a
stable release.  If the only criterion is that the release compiles
the (extended) regtests satisfactorily, then I doubt that adequate
attention will be directed to bugs discovered after the release
that would be deemed critical on the current definition.  That
would seriously degrade the quality of our stable releases.

2. To complete the discussion David and I were having about
the possibility of using revert as an option to fix a critical bug,
I looked at a few recent critical regressions, namely those
which caused Release Canditates 6 and 7 to be abandoned.
None of these could have been easily fixed by reversion,
either because the fix was complicated, the original source
was too old for revert to be safe, or the cause was external
to LP.  So reversion offers no easy answer.

3. I rather like the idea of leaving the decision about the time
to make a stable release to an individual.  That's what Han-Wen
used to do in the old days, IIRC.  That individual could use
tests of his own devising to help him make a decision, but I
would expect him/her to at least canvas views from developers
before deciding.  But I worry that this would still suffer from
the problem I outlined in (1) above.  Perhaps that release-
meister could identify bugs which (s)he considers are blocking
a new stable.  That would get round (1), and ensure serious
bugs are attended to promptly.

4. The other possibility is to adopt timed releases.  Say every
6 months.  The .0 release would be made with a statement 
about any critical bugs, which would be fixed in a .1 release.
Still suffers from (1), so I don't favour this.

On balance, assuming such a person could be found, I would
favour a solution along the lines of (3) above.

Trevor