Re: keep git master clean

[Carl Sorensen]

On 12/15/10 10:57 AM, "Graham Percival" <address@hidden> wrote:

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

So can I consider it valid if I run make doc (not make doc-clean && make
doc) and make test and both succeed?

I'm in the midst of a make test right now.  I'll get you my estimate of make
test time when I'm done.  Of course, in this particular case, in order to
verify, I also have to do a make test-clean, because the bad regtest is part
of the snippet database, and I need to purge it.

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

I think you are severely underestimating the time on this task, but that may
be just because I don't understand the build system at all.  I'm not
advocating spending these 200 hours, by the way.

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

I'm totally OK with that.  I think I need to be more careful.  I will try to
do better.  

And I'm not at all offended by your original email, even if it was a bit
harsh.  We're all working together with one main objective -- getting 2.14
out.  And it's so close I can taste it!

I've got a plan for a patch to 1290 stewing in my subconscious -- I may be
able to get it done next week.  If I can do that, we've got a branch point!

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

This would be totally cool.  I was just about to ask if there is some way to
manage the "errors as warnings" flag from inside the regtests.

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

I'm also totally OK with throwing out the 1440 regtest.  I was just about to
do it when you did it.

Thanks,

Carl