lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cherrypicking our way to 2.16


From: Graham Percival
Subject: Re: cherrypicking our way to 2.16
Date: Sat, 30 Jun 2012 23:08:36 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Sat, Jun 30, 2012 at 11:41:49PM +0200, address@hidden 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
were from new code where people skipped the countdown?  and how
many issues were from new code but were not found in the
countdown?

At a completely wild guess, I'd go with 50% pre-2012, 10%
skipping, and 40% new code.  But I'd really love to have some hard
numbers.
(and I don't think we can have a meaningful discussion about this
until somebody _does_ go and find those hard numbers.  ETA 3 hours
to find all issues -- note that google issues can give you a
spreadsheet, and/or you can make queries via JSON -- and skim the
discussion about each issue to find where it was introduced and
how it was resolved)

- Graham



reply via email to

[Prev in Thread] Current Thread [Next in Thread]