lilypond-devel
[Top][All Lists]
Advanced

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

Re: Regression tests


From: Graham Percival
Subject: Re: Regression tests
Date: Sun, 6 Jun 2010 15:01:33 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

On Sun, Jun 06, 2010 at 07:29:03AM -0600, Carl Sorensen wrote:
> 
> I'm moving all of the detail out of 3.6.3 Post-compilation options into 8
> Regression tests.

Great!

>  You can learn more about testing in the
> documentation."  (I can't put a link here, because this is part of the
> COMPILING file).

I think you mean INSTALL.txt.  We currently *do* have such links,
such as in the very first text paragraph of that file.

I suppose we could discuss if we *should* have those links, or how
they should be formatted, or some-such.  However, I veto that
discussion for now.  We've spent *far* too much time recently
talking about doing stuff and not actually doing it.
(if somebody desperately cares about this particular item, add it
to the tracker as priority-postponed, with a note that I'm being a
jerk and refusing to discuss/decide anything until later)


With that in mind, please add a link.  Since it's in
Documentation/included/compile.itexi, you need to use @rcontrib{}
even though you're linking within the CG.


> I've reordered CG 8.  Tentative organization is:
> 
> Introduction to regression tests
> Precompiled regression tests
>     Regression test output
>     Regression test comparison
> Compiling  regression tests
> Identifying code regressions
> Other tests
>     Checking memory usage
>     Checking code coverage
> MusicXML tests

I don't like "other"... what about "Performance tests"?  no wait,
that doesn't work for code coverage.  Hmm.

Separate topic: is the distance-output script going to be
discussed in Compiling regression tests?  In my mind, there's a
difference between compiling the regtests (i.e. "do any errors
break compilation?") and examining the before+after changes for a
patch.


> I haven't yet figured out where the information on what you need to do after
> modifying fonts should go.  My recent experience has shown me that you don't
> need to do a make clean after modifying fonts.  It's sufficient to do rm
> mf/out/*; that triggers a font rebuild.

*shrug*
I wouldn't expect that to make a huge difference in time, although
of course if you're doing heavy font work, I guess that saving 3-4
minutes for each compile *would* help a lot.
For now, I'd dump it somewhere in the Programming chapter;
eventually we might split off a Font chapter from that.  But I'd
really caution against trying to juggle too many balls at once --
dump it somewhere and then focus on the Regressions chapter.

> I also haven't yet decided where to put the whole "Typical developer's
> edit/compile/test cycle" node.  I'm currently thinking that there should be
> a section in the CG on "The LilyPond build system", but I haven't worked
> that out fully yet.

There's already one in CG 3.  It doesn't particularly belong
there, but I was dumping it somewhere to avoid too much juggling.

>  But since you got me started, here's my initial draft:
> 
> The LilyPond build system
>     Intro to build system
>     Make
>     Auxiliary scripts
>     GUB

GUB is discussed in Releases.  I don't think that needs to change.

> 3.10 would go away under this organization.

oh, oops, you already knew about it.


> Of course, as this is a major reorganization of the docs, I'll post a patch
> on Rietveld before committing.

I'm seeing too much juggling.  Focus on the Regressions -- dump
all other info into the CG (anywhere that makes remote sense,
other than CG 1, 2, and 7).  Don't bother with a patch-review for
that info-dump.  Then work carefully on Regressions, post a patch,
etc.

We'll come back to those other sections later.

Cheers,
- Graham



reply via email to

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