Re: Stable 2.16 releases (dictator)

[David Kastrup]

"Trevor Daniels" <address@hidden> writes:

> David Kastrup wrote Saturday, July 14, 2012 9:30 AM
>
>> 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.
>
> I don't understand exactly what you are saying here.  I get the
> drift, but it would be helpful if you could explain it with reference
> to stable branches and master more precisely.

Priorities may change after the first stable release of a major version
branch.  With respect to this proposal: priorities may change after
2.16.1.

>> 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.
>
> So during some period a few weeks prior to the next stable,
> selected updates passing review might be marked 'patch-hold'
> rather than 'patch-push'?  I'd be happy with that.

No.  Development is not affected unless I specifically ask for it.  But
it need not really be put into a policy.  If it turns out that it is
necessary, I expect other developers to listen like I would listen to
them in turn if they have a problem affecting their work.

Basically the only policy this boils down to is "people committing
patches should read lilypond-devel regularly".  We might consider
special subject lines to make it easier to keep track of important
things.  Again, this is not specific to the 2.16 release process in
itself.

>>>    - 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 suggest that you keep any such decision to yourself until
> just before the next stable is built, or defer making it until
> then.  Otherwise interest in fixed such bugs will wane.

And in the interest of making a release, I want to have people
prioritize on those bugs that will affect the release.  That's the main
point of having priorities in the first place.

-- 
David Kastrup