Re: deleting files in input/test

[Graham Percival]

On Wed, 11 Jun 2003 00:36:52 +0200
Jan Nieuwenhuizen <address@hidden> wrote:
> > > ac-extra-voice.ly
> > 
> > Jan added a  docstring, but to be frank, I still don't get the point
> > of this file.
> 
> It's not described in the manual and when I needed it (years ago), I
> found it not trivial to accomplish.

(after latest Jan email)
OK, I think I see the point now.  We'll keep it, although I'll probably
change the filename (if only to write out "autochange-extra-voice.ly")

> > > beam-chord.ly
> 
> The new comment says:
> 
>    Hmm. what's this supposed to test?beam-chord.ly
> 
> Ahem.  While I agree that it would be good to have better and
> organised test files, this particular one happens to exhibit an awful
> regression bug (the beams need to be horizontal, of course).  Please
> guys, *look* at the examples and output before junking them.

I see that somebody already marked this as "move to REGTEST"; good.

But I'd just to make sure I'm doing the right thing: as far as I
understand, input/test is supposed to be examples to demonstrate tricky
things you can do with Lilypond.  input/regression is supposed to be for
code snippets which "test" new version of Lilypond to make sure they do
everything they're supposed to.

While I'm looking at an input/test file, currently I only look at
whether that file demonstrates something useful for an end-user.  I
don't try to judge whether the file is useful in regression testing; in
part because I thought that was what input/regression was for, but
mainly because I don't know enough about Lilypond internals (or
engraving, for that matter -- I didn't know that the beams needed to be
horizontal) to judge whether or not it's a useful regression test.

(sometimes I'll mark a file as "delete or move to regression"; I don't
_totally_ ignore the usefulness of a code snippet in regression testing)

Is this what I should be doing?  I'll never delete a file without asking
if it's ok on the mailist, so if a file is needed for regression, somebody
can tell me and it'll get moved instead of deleted.

> > > beam-pos.ly
> 
> Let's keep it at least until we fix the bug it shows (the f32 beam).
> We can do without the last line, or better even, replace it by some
> 64th beams.

When you say "keep it", do you mean "keep it in input/test", or "move
it to input/regression and keep it there"?
(or even "move it to input/bugs and keep it there")

> > > beam-second.ly
> 
> 
>    TODO: what's this for? beam-second.ly
> 
> Seconds are tricky.  We used to have problems with seconds being too
> steep, or getting too long stems.  In a file like this, showing
> seconds, you'll spot something fishy very quickly (if you get to look
> at it).

Should we move it to regression?


Cheers,
- Graham