Re: Stable 2.16 releases (dictator)

[Trevor Daniels]

David Kastrup wrote Saturday, July 14, 2012 9:30 AM


> Graham Percival <address@hidden> writes:
> 
>> Let’s appoint David Kastrup as the “benevolent dictator” of the
>> stable/2.16 git branch.

I'm happy to go along with this.  It's hardly a policy, but it
will definitely move things along!
  
> Well, it definitely makes sense before an extra round of discussion that
> I acknowledge to be willing to take that job.  Which I do.

Thanks David.

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

Trevor