Discussions on LilyPond development

mike@mikesolomon.org | 30 Jun 2012 23:41

cherrypicking our way to 2.16

Hey all,

Once the most recent critical issues are squashed, are people up for forking off a stable branch from 2.15?
Administratively we'd go into cherrypick mode like we did for 2.13 where we institute a moratorium on
pushing to the stable branch and have a cherrypick Czar (like Carl was a year-ish ago) port critical
bugfixes to this branch. All release candidates would come from this branch.

Cheers,
MS

headers

Graham Percival | 1 Jul 2012 00:08

Re: cherrypicking our way to 2.16

On Sat, Jun 30, 2012 at 11:41:49PM +0200, mike <at> mikesolomon.org wrote:
> Once the most recent critical issues are squashed, are people up
> for forking off a stable branch from 2.15? Administratively we'd
> go into cherrypick mode like we did for 2.13 where we institute
> a moratorium on pushing to the stable branch and have a
> cherrypick Czar (like Carl was a year-ish ago) port critical
> bugfixes to this branch.

We never did that for 2.13.  You're thinking of 2.14, a few months
after 2.14.1.

I'm against this for a few reasons:
- we'd need a volunteer to handle this cherry-picking (but of
  course your email may prompt somebody to offer)
- we still don't have anybody else who has made a release, and I'm
  already having trouble running GOP (let alone GLISS).
- after a potential branch, git master is not going to get regular
  regression tests (other than Patchy) -- nobody is going to be
  making releases from it.

I still think that the extra burden should be on people wanting to
be unstable, not on people wanting to be stable.  That is, if
somebody knows that they're doing big hacking (spacing changes,
rewriting the parser, etc), then they should stick that on a
separate branch.  One of the big "selling points" of git is that
it makes branching and merging easier.

That said, it would be interesting if somebody analyzed all
Critical issues from Feb 2012 onwards (after we started Patchy).
How many issues were related to code before 2012?  How many issues

(Continue reading)

headers

David Kastrup | 1 Jul 2012 06:25

Re: cherrypicking our way to 2.16

"mike <at> mikesolomon.org" <mike <at> mikesolomon.org> writes:

> Hey all,
>
> Once the most recent critical issues are squashed, are people up for
> forking off a stable branch from 2.15? Administratively we'd go into
> cherrypick mode like we did for 2.13 where we institute a moratorium
> on pushing to the stable branch and have a cherrypick Czar (like Carl
> was a year-ish ago) port critical bugfixes to this branch. All release
> candidates would come from this branch.

That sounds like a good idea, but the typical death of our release
candidates was by regressions more than a month old rather than
last-minute work done before the release candidate.  Our "stable branch"
basically is the last development release.

So while this sounds eminently reasonable, it does not seem to
significantly help with out current situation.

--

-- 
David Kastrup

headers

Carl Sorensen | 1 Jul 2012 06:30

Re: cherrypicking our way to 2.16


On Jun 30, 2012, at 10:26 PM, "David Kastrup" <dak <at> gnu.org> wrote:

> "mike <at> mikesolomon.org" <mike <at> mikesolomon.org> writes:
> 
>> Hey all,
>> 
>> Once the most recent critical issues are squashed, are people up for
>> forking off a stable branch from 2.15? Administratively we'd go into
>> cherrypick mode like we did for 2.13 where we institute a moratorium
>> on pushing to the stable branch and have a cherrypick Czar (like Carl
>> was a year-ish ago) port critical bugfixes to this branch. All release
>> candidates would come from this branch.
> 
> That sounds like a good idea, but the typical death of our release
> candidates was by regressions more than a month old rather than
> last-minute work done before the release candidate.  Our "stable branch"
> basically is the last development release.

The cherry-picking I did was not in order to get 2.14 out, but rather to backport fixes from 2.15 into 2.14.x.
At least, iirc.  

Thanks,

Carl