]> git.donarmstrong.com Git - lilypond.git/blobdiff - Documentation/contributor/regressions.itexi
PO: modifying po-replace before integrating it to the release process
[lilypond.git] / Documentation / contributor / regressions.itexi
index 2c7783c1d7828e578c0ca940e24ecc6eab006264..5de3f8aa918572a3cbe34e9b0b6ec1fda61e2b97 100644 (file)
@@ -183,7 +183,8 @@ than building the source code, as described in
 @node Regtest comparison
 @section Regtest 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
 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
@@ -485,7 +486,9 @@ 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.
 
 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:
 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:
@@ -505,6 +508,7 @@ or @rinternalsnamed{Top, Internals Reference}.
 Vague descriptions (like "behaves well", "looks reasonable") shouldn't be used.
 
 @ignore
 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
 @subsubheading Is regtest straightforward and systematic?
 
 Unfortunately some regtests are written poorly.  A good regtest should be