From: Phil Holmes <mail@philholmes.net>
Date: Sat, 11 Feb 2017 14:36:54 +0000 (+0000)
Subject: Remove regtest checking exercise from CG
X-Git-Url: https://git.donarmstrong.com/lilypond.git?a=commitdiff_plain;h=df7bf1e9f95f93572d6d252a5acbedfebc8f30e8;p=lilypond.git

Remove regtest checking exercise from CG
---

diff --git a/Documentation/contributor/regressions.itexi b/Documentation/contributor/regressions.itexi
index 9b13c25d53..1963a6bebc 100644
--- a/Documentation/contributor/regressions.itexi
+++ b/Documentation/contributor/regressions.itexi
@@ -11,7 +11,6 @@
 * Finding the cause of a regression::
 * Memory and coverage tests::
 * MusicXML tests::
-* Grand Regression Test Checking::
 @end menu
 
 
@@ -542,49 +541,3 @@ available in the LilyPond documentation:
 @uref{http://lilypond.org/doc/latest/input/regression/musicxml/collated-files}
 @end example
 
-
-@node Grand Regression Test Checking
-@section Grand Regression Test Checking
-
-@subheading What is this all about?
-
-Regression tests (usually abbreviated "regtests") is a collection
-of @file{.ly} files used to check whether LilyPond is working correctly.
-Example: before version 2.15.12 breve noteheads had incorrect width,
-which resulted in collisions with other objects.  After the issue was fixed,
-a small @file{.ly} file demonstrating the problem was added to the regression
-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.
-
-@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.philholmes.net/lilypond/regtests/}
-@end example
-
-@subheading Some tips on checking regtests
-
-@subsubheading Description text
-
-The description should be clear even for a music beginner.
-If there are any special terms used in the description,
-they all should be explained in our @rglosnamed{Top, Music Glossary}
-or @rinternalsnamed{Top, Internals Reference}.
-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
-straightforward: it should be obvious what it checks and how.  Also, it
-usually shouldn't check everything at once.  For example it's a bad idea to test
-accidental placement by constucting one huge chord with many suspended notes
-and loads of accidentals.  It's better to divide such problem into a series
-of clearly separated cases.
-@end ignore