Re: Stable 2.16 releases (dictator)

[David Kastrup]

Graham Percival <address@hidden> writes:

> I will officially introduce this next Tuesday, but since it's now
> a hot topic, let's have an extra round of discussion and fixing
> before then.
>
> http://lilypond.org/~graham/gop/gop_3.html
>
>
> *** Summary
>
> Let’s appoint David Kastrup as the “benevolent dictator” of the
> stable/2.16 git branch.

Well, it definitely makes sense before an extra round of discussion that
I acknowledge to be willing to take that job.  Which I do.  I don't
commit to more than that at the current point of time (it is still quite
likely that I will have to abandon LilyPond in order to make a living),
and it is also possible that I will at one point of time seek out a
transfer of control.

After the first release, the focus of branch maintenance will go from
_defining/shaping_ a stable release to _maintaining_ it.  That seriously
changes the importance of avoiding new regressions even of minor nature,
and rules out most "useful" changes that are not strictly confined in
effect on current behavior and/or bugfixes.  While the next stable
release branch is far from being released, well-isolated _additions_ in
functionality without effect on previously valid files may be subject to
consideration.

In any case, after the first release of the stable branch decisions on
it should become quite more conservative, and it may be that handing
responsibility off might make for a better fit.  It is also conceivable
that a rule-based approach will work better when the release urgency is
gone, though I consider it likely that overruling automatisms would more
likely happen in the opposite direction, namely excluding updates that
may have passed the formal review times, but which the maintainer is not
sufficiently confident about.

Long talk short: this is not as much a policy but a plan.  It does not
tell us how to proceed once the plan has reached its goals (or failed to
do so), something which a policy would.  But I think we will be better
set to draft a formal policy when we have seen the outcome from this
plan.

[...]

> 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.

It will likely often be a good answer.  Just not reliably enough to turn
it into a hard and fast rule.

> *** Details
>
> The policy is: David Kastrup has sole authority over what goes
> into stable/2.16 and which release(s) will have a version number
> of 2.16.x, until 2012 Dec 31.

Or until he asks to relinquish control, or there is sufficient agreement
among core developers that he should.

> In more detail, this means:
>
>    - he decides when to have 2.16.0.
>    - he may classify issues as being issue-Critical, but he can
> still make a 2.16.x release even if there are Critical issues if
> he chooses to do so. Nobody else can denote issues as being
> Critical.

Being able to look at a list of Critical issues is useful to make sure
no oversights happen.  So I'd propose that we use the same rules as
before for marking issues as Critical (in particular, letting a
regression automatically imply a Critical issue), but that I have the
leeway of downmarking and/or ignoring them.  I am not entirely happy
with that, partly because we have too few categories of "Critical", and
I think not all of what may be considered "Critical" is really
exclusively related to the next stable release.

>    - translators do not merge or cherry-pick onto stable/2.16
> unless specifically requested to do so.

Or the other direction.  stable/2.16 will basically be a candidate for
release, and if that candidate is dropped, the next candidate quite
possibly is not a direct descendant of the previous candidate, since
usually a candidate will be some unstable release plus additional
fixes/reverts/cherry-picks.  So nobody should cherry-pick or merge
_from_ this branch either, in particular not into the mainline, since
release-specific fixes might be unsuitable for the development branch.

-- 
David Kastrup