Graham Percival <gra...@percival-music.ca> writes:
> On Tue, Jan 24, 2012 at 12:35:17PM +0100, David Kastrup wrote:
>> has less potential to go wrong if there is a problem at any time. I
>> actually don't really understand why we bother with restoring the tree
>> anyway instead of removing it and doing the next test from a freshly
>> created
>> git clone
>> directory.
>
> That loses the regtest baseline, and the whole point is to do a
> regtest comparison.
Copy it over. Takes few seconds. Something like
cd /usr/tmp/checkoutwithbaseline
find -name out-baseline -exec cp -a {} /usr/tmp/othercheckout/{}
should do the trick.
> It's certainly possible to move the baseline to a separate
> directory, remove the current build+src dirs, recreate the
> build+src dirs from scratch, then move the baseline back into the
> build dir and make a comparison.
Really.
> ETA: 10 hours for anybody other than Julien, because this touches
> some dark corners of the build system.
I don't see the dark corners.
>> I suppose we'll get to see the proof when this moves to staging.
>
> Not quite; staging doesn't do a regtest comparison. We'll see the
> proof once it's in master and there's a new official GUB release.
Great.
>> So that this does not get needlessly messy in case anything _does_ go
>> wrong, I am currently in the process of moving the non-controversial
>> parts of 2240 into staging where they can get advance testing.
>
> If there _is_ something wrong with the patch -- and I'm not saying
> that there is, just that the only evidence I've seen that it's ok
> comes from your emails -- then the only other testing that staging
> provides is making sure that the docs compile from scratch. If
> regtests broke, we wouldn't see that until the official 2.15.28
> release.
I am doing the regtests even though it takes hours, and I don't see the
problems you did. I am not trying to sabotage anything here, but I
really can't think that anything but a broken test setup or a different
master could be responsible. I'll be reducing the review patch
accordingly when I see parts move into master, to facilitate testing
before the "large" commit, and I would appreciate hearing about how they
check out.
It should even be possible to move the rhythmic engraver itself into
staging in advance (and thus get the "real" patch smaller and make
certain that the preconditions for the "actual" patch are met) without
causing a change in behavior.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
