Re: GOP2-2b - Stable 2.16.x releases (dictator) (probable decision)

[David Kastrup]

Copying to user list because of the LSR angle.

Graham Percival <address@hidden> writes:

> ** Regressions
>
> (mostly copied from an email by Trevor)
>
> 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.
>
> 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.

As another data point: So far the next unstable release 2.15.42 has 56
bugs marked as Fixed, with 7 marked as regressions (a mere 12.5%).
2.15.41 has been released on July 4th, a bit more than three weeks ago,
meaning that we currently are running at 2 regressions detected/fixed
per week.  This may be a bit above average, but it still makes it
unlikely that a prolonged absence of regressions will be a workable
release criterion anytime soon.

In any case, it seems inevitable at the current pace of development to
have a stabilizing branch for the goal of a stable release, and fixes to
this branch will have to be gatewayed by decisions about their potential
for causing regressions.

I will state some things with regard to how I plan to proceed with the
powers vested in me, and what consequences outside of the immediate
range of those powers will arise:

At the time the 2.16 branch will be cut, the versioning for the unstable
branch will need to advance to 2.17 in order to maintain an ordered
relation between version numbers and LilyPond language.

I will want a reasonable chance of getting the stable release tested.
We have had so far eight unstable releases declared as 2.16 release
candidate, the first about a year ago.  The excitement will have been
worn off somewhat.  What versioning should I be using for the release
candidates?  Numerically, one has the options to start with

2.15.95

or with

2.16.0.95

leading up to a 2.16.1 release as the first official stable release.
The disadvantage of the latter is that I don't really have a clue how
the MY_PATCH_LEVEL system is supposed to tie into the release
procedures.

The disadvantage of the former is that we'll want to run all the version
updating procedures at the moment we split into a 2.17 and a 2.16
branch.  If anybody has relevant input on that, this will be welcome.
We also want to have the prereleases be eligible for the unfrozen alphas
(feature prereleases or whatever) of upcoming GNU/Linux and other
distributions.

The current pace of development also means that at the time the branch
will get cut, we are in a fast progressing state.  I don't see that it
would be conscionable to declare a stable release cut directly out of
this line of development.  So I definitely will have to tend to a stable
branch, and one that gets a serious chance of getting serious testing.

One of the reasons to release a stable release is to get the benefits
and excitement to it about users and distributors.  For that reason, I
would like to have the LSR updated.  Since it is supposed to be a
resource helpful to "average" users, that would mean that for a while,
optimally two versions should be available in parallel, one for 2.14,
one for 2.16.  At first the 2.16 version just as a "beta" or something,
later the 2.14 as a "fallback" or so.

I have no idea how feasible this would be, but if we manage to
eventually get to a reasonable stable release schedule, the usefulness
of this resource would be increased by supporting more than just one
stable release.  While the snippets in our documentation are available
at several versions, there is no web interface to them.

So that are my current thoughts about what kind of cooperation I will
require to pull off my duties as the upcoming 2.16 dictator.

-- 
David Kastrup