Re: keep git master clean

[Graham Percival]

On Wed, Dec 15, 2010 at 10:34:59AM -0700, Carl Sorensen wrote:
> We've got to have some better process to handle this.

Agreed.

> I don't know what it is.

For a symptomatic treatment, this particular case could be checked
with
  make test
instead of make doc.  That'd be 5-10 minutes instead of an hour.
Not ideal by any means, but better than nothing?

> Maybe a correct build system, so we don't need to do make doc-clean to
> ensure things aren't broken.

I'm pegging this at 200 hours, and I don't think I'm
overestimating.  That's a lot of bugfixes, new features,
CG-writing, etc.  :(

> Maybe a separate branch that we can push changes to and only
> gets moved to master once a week when it's been verified by a
> build-meister.

That's an interesting idea... I'll add it to the GOP list.  If we
can't find a technical solution, this might be the least-bad
alternate option.

> I can see the problem with confusing the new contributors.  And I think we
> should avoid it.

I think the best short-term solution is:
  1. accept that breakage sometimes happens.  Sorry, my initial
     email was a bit too harsh for this.
  2. accept that if a patch breaks something, revert it.  No
     blame, no harm, no foul.  Just get git master working again,
     then start discussing a fix.


For this specific regtest, I've been building groundwork for
splitting the regtests into different directories (including one
for "lilypond does not segfault if foo" or "lilypond should
produce an error if bar").  Once we did that, we could make sure
that tests which are intended to throw an error actually do throw
an error, and not balk at the compile.

The butcher's bill for that idea is 40 hours, BTW.  And
unfortunately, all the estimates in this email are for
main-developer-time, not estimated-frog-time.  :(

Until/unless that happens, let's just nuke the 1440 regtest.
There are *so* many other things in lilypond that are worse than
that one.  We're in a total triage situation here.

Cheers,
- Graham