Re: Stable release state

[Trevor Daniels]

David Kastrup wrote Saturday, April 06, 2013 10:07 AM

>  it is clear that master has stopped being suitable for turning into a
> stable branch.  There are several ways forward, none of them
> particularly endearing.
> 
> a) cut the stable branch before the last batch of changes and accumulate
> only bug fixes of simple nature and/or regression fixes into it from now
> on.  

This is the option I prefer.

> The problem with that approach is that we have a _lot_ of
> outstanding bug fixes, partly because we have not a single developer who
> could be bothered about catering even for trivial documentation fixes
> like <URL:http://code.google.com/p/lilypond/issues/detail?id=3151>
> (dormant for two months after reporting, and we have quite a few of that
> class pending).  That basically means that I'll be responsible for
> fixing all of the Frog-class bugs necessary to get into release state,
> and also cherry-pick all of those bugs.  

Not necessarily; with a new stable in the offing doc writers usually
knuckle down and try to catch up.  Writing documentation while
things are unstable can be frustrating.  Also developers will be reluctant
to see their their work holding up a new stable because of unfixed
bugs.  The key is to make a start by branching off.  

> There won't be useful input from users of master since master is allowed
> to seriously diverge and those changes will capture the attention of
> testers more than long-standing small fixes.

Candidate releases should be used for encouraging testing.

And I agree with Werner - I'd be happy to see you take overall control
of the branched-off stable; leaving master to continue on as before.

Trevor