CG: add information about Regtest Checking Project

CG: add information about Regtest Checking Project

Phil Holmes wrote a nice web app that allows people to
review regtests, one at a time.  We can ask users for
help and thus painlessly do a full regtest check.
This commit contains brief instructions how to use the app.

[janek, 2012-02-14 17:54:39]

Please review.
The most important question is: will this be clear for average user, who hadn't
participated in development previously?

[Graham Percival, 2012-02-14 18:33:06]

http://codereview.appspot.com/5669047/diff/1/Documentation/contributor/regres...
File Documentation/contributor/regressions.itexi (right):

http://codereview.appspot.com/5669047/diff/1/Documentation/contributor/regres...
Documentation/contributor/regressions.itexi:511: it shouldn't check everything
at once.  For example it's a bad idea to test
I disagree slightly here: most regtests should only do a single thing, but a few
(deliberately) test multiple ones.  For example, there's some piece by IIRC
Schubert which uses every type of grob (or something like that; I just remember
being told off by Jan for deleting that regtest so I had to rescue it from git
history).

Ideally those regtests would be clearly marked as separate from the others, but
since that hasn't been done, I don't think we should ask users to complain about
large regtests.

[janek, 2012-02-14 22:24:39]

http://codereview.appspot.com/5669047/diff/1/Documentation/contributor/regres...
File Documentation/contributor/regressions.itexi (right):

http://codereview.appspot.com/5669047/diff/1/Documentation/contributor/regres...
Documentation/contributor/regressions.itexi:511: it shouldn't check everything
at once.  For example it's a bad idea to test
On 2012/02/14 18:33:06, Graham Percival wrote:
> I disagree slightly here: most regtests should only do a single thing, but a
few
> (deliberately) test multiple ones.

Yes, a few regtests are engravings of whole pieces.  But since they are rare,
the people checking the results of the survey will handle them.

Nevertheless, i rephrased this a bit and added "usually".

[Graham Percival, 2012-02-17 12:04:10]

http://codereview.appspot.com/5669047/diff/5001/Documentation/contributor/reg...
File Documentation/contributor/regressions.itexi (right):

http://codereview.appspot.com/5669047/diff/5001/Documentation/contributor/reg...
Documentation/contributor/regressions.itexi:512: accidental placement by
constucting one huge chord with many suspended notes
uh, wait a moment.  Don't you want to check that accidentals don't collide with
each other?  How can you do that without having one huge chord?

I really think you should remove this subheading entirely.  It's difficult to
read, and I'm not certain that changing the regtests in this way would even be a
good idea.  Get the other parts accepted first, and then we can argue about this
additional portion later if you really insist.

[janek, 2012-02-22 23:24:22]

New patch set uploaded.

On 2012/02/17 12:04:10, Graham Percival wrote:
>
http://codereview.appspot.com/5669047/diff/5001/Documentation/contributor/reg...
> File Documentation/contributor/regressions.itexi (right):
> 
>
http://codereview.appspot.com/5669047/diff/5001/Documentation/contributor/reg...
> Documentation/contributor/regressions.itexi:512: accidental placement by
> constucting one huge chord with many suspended notes
> uh, wait a moment.  Don't you want to check that accidentals don't collide
with
> each other?  How can you do that without having one huge chord?

i want to check more than whether accidentals don't collide (they should be
placed in certain order, and there's also the "should flats sixth apart be
staggered or not" thingy, and so on)

> I really think you should remove this subheading entirely.  It's difficult to
> read, and I'm not certain that changing the regtests in this way would even be
a
> good idea.  Get the other parts accepted first, and then we can argue about
this
> additional portion later if you really insist.

OK.  I'm really sure that some regtests should be designed in a different way,
but this indeed can wait.
Probably an example would be nice here.

Could you help me with links to music glossary and internals?  Julien wrote that
they are wrong, and i don't know how they should be done (and i'm really busy so
if you can save me 15 minutes of searching i'd be grateful).

cheers,
Janek

[janek, 2012-02-25 21:51:31]

New patch set uploaded, it should make doc now.

Thanks for the tips, Carl and Graham!  You saved me some time.

I decided not to use @rglos and @rinternals (because from what i understand it
would print the name of the section i'm referring to) but use @rglosnamed and
@rinternalsnamed instead. This worked nice in html manual, but in pdf i got:
"...explained in our Section “Music Glossary” in Music Glossary
Chapter 9: Regression tests 98
or Section “Internals Reference” in Internals Reference."
Not perfect... shall i use regular references or don't worry about this?

[janek, 2012-02-25 22:01:07]

On Sat, Feb 25, 2012 at 10:55 PM, Graham Percival
<graham@percival-music.ca> wrote:
> Up to you.  The fancier you make the formatting, the harder it is
> to maintain.  You should also check how it looks in info.  If you
> want to play games with that, go ahead -- as I said, we don't
> forbid @...named.  But I personally would just use the standard
> @rglos and accept whatever that produces.

Done.

[janek, 2012-02-26 16:38:21]

Screw this; i tried using regular refs but they produced  hideous effects in
html. I'm going back to named references; they are not perfect but acceptable
i'd say.

[janek, 2012-03-02 22:30:50]

pushed as 90ee61d5b681295b8b401128ca9bc48554eee66a
closed