The test comparison shows all of the changes that occurred between
the current release and the prior release. Each test that has a
-significant difference in output is displayed, with the old
-version on the left and the new version on the right.
+significant (noticeable) difference in output is displayed, with
+the old version on the left and the new version on the right.
+
+Some of the small changes can be ignored (slightly different slur
+shapes, small variations in note spacing), but this is not always
+the case: sometimes even the smallest change means that something
+is wrong. To help in distinguishing these cases, we use bigger
+staff size when small differences matter.
+
+Staff size 30 generally means "pay extra attention to details".
+Staff size 40 (two times bigger than default size) or more means
+that the regtest @strong{is} about the details.
+
+Staff size smaller than default doesn't mean anything.
Regression tests whose output is the same for both versions are
not shown in the test comparison.
@node Regtest comparison
@section Regtest comparison
-Before modified code is committed to master, a regression test
+Before modified code is committed to @code{master} (via @code{staging}),
+a regression test
comparison must be completed to ensure that the changes have
not caused problems with previously working code. The comparison
is made automatically upon compiling the regression test suite
tests as a proof that the fix works. If someone will accidentally break
breve width again, we will notice this in the output of that regression test.
-We are asking you to help us by checking a regtest or two from time to time.
+@subheading How can I help?
+
+We ask you to help us by checking one or two regtests from time to time.
You don't need programming skills to do this, not even LilyPond skills -
just basic music notation knowledge; checking one regtest takes less than
a minute. Simply go here:
@example
-@uref{http://www.holmessoft.co.uk/homepage/private/regtests/}
+@uref{http://www.philholmes.net/lilypond/regtests/}
@end example
@subheading Some tips on checking regtests
Vague descriptions (like "behaves well", "looks reasonable") shouldn't be used.
@ignore
+this may be useful for advanced regtest checking
@subsubheading Is regtest straightforward and systematic?
Unfortunately some regtests are written poorly. A good regtest should be