CG: change some references from master to staging.

diff --git a/Documentation/contributor/doc-work.itexi b/Documentation/contributor/doc-work.itexi
index dabb13beb4b581609003bce4fd6e6c7f0b60138f..cdf0e26f8d518de9487f8198bc53f7c3054ad0ff 100644 (file)
--- a/Documentation/contributor/doc-work.itexi
+++ b/Documentation/contributor/doc-work.itexi
@@ -2234,31 +2234,44 @@ This policy explains how to manage Git branches and commit
 translations to Git.
 
 @itemize
-@item Translation changes matching master branch are preferably made on
-@code{translation} branch; they may be pushed directly to
-@code{master} only if they do not break compilation of LilyPond and
-its documentation, and in this case they should be pushed to
-@code{translation} too.  Similarly, changes matching
+@item Translation work is made on
+@code{translation} branch.  This branch is merged on
+@code{staging} once a week, approximately.  Then,
+@code{master} branch is merged on
+@code{translation}, where the check-translation script (see
+@ref{Check state of translation}) shows changes in English docs which
+should be translated, and the cycle starts again.
+
+@item Translations may be pushed directly to
+@code{staging} only if they do not break compilation of LilyPond and
+its documentation.  Those changes could be pushed to
+@code{translation} too, or alternatively translators could wait until
+they come from
+@code{master} the next time it is merged on
+@code{translation}.  Similarly, changes matching
 @code{stable/X.Y} are preferably made on
-@code{lilypond/X.Ytranslation}.
+@code{X.Ytranslation}.
 
 @item @code{translation} Git branch may be merged into
-master only if LilyPond (@command{make all}) and documentation
-(@command{make doc}) compile successfully.
-
-@item @code{master} Git branch may be merged into
-@code{translation} whenever @command{make} and @command{make
-doc} are successful (in order to ease documentation compilation by
-translators), or when significant changes had been made in
-documentation in English in master branch.
+@code{staging} branch only if LilyPond (@command{make all}) and
+documentation (@command{make doc}) compile successfully.
+
+@item @command{make} and @command{make doc} are usually successful in
+@code{master} Git branch because those tests should have already
+succeeded in
+@code{staging} branch before merging.
+@code{master} branch may be merged into
+@code{translation} when significant changes had been made in
+documentation in English in
+@code{master} branch.
 
 @item General maintenance may be done by anybody who knows what he does
 in documentation in all languages, without informing translators
 first.  General maintenance include simple text substitutions
 (e.g. automated by sed), compilation fixes, updating Texinfo or
 lilypond-book commands, updating macros, updating ly code, fixing
-cross-references, and operations described in @ref{Maintaining
-without updating translations}.
+cross-references, and operations described in
+@ref{Maintaining without updating translations}.
 @end itemize
 
 

diff --git a/Documentation/contributor/introduction.itexi b/Documentation/contributor/introduction.itexi
index bb0f9849350575ddeccd4029a0a119aea85d5fac..0883a1a81603c9f987823905c3a043f261b7bc3d 100644 (file)
--- a/Documentation/contributor/introduction.itexi
+++ b/Documentation/contributor/introduction.itexi
@@ -183,7 +183,7 @@ who will push it for you.
 @end enumerate
 
 @advanced{Yes, this process means that most patches wait between
-60-120 hours before reaching master.  This is unfortunate, but
+60-120 hours before reaching @code{master}.  This is unfortunate, but
 given our limited resources for reviewing patches and a history of
 unintended breakage in @code{master}, this is the best compromise
 we have found.}

diff --git a/Documentation/contributor/regressions.itexi b/Documentation/contributor/regressions.itexi
index a5dac4822651ec72a8b5611a71d031d907747199..5de3f8aa918572a3cbe34e9b0b6ec1fda61e2b97 100644 (file)
--- a/Documentation/contributor/regressions.itexi
+++ b/Documentation/contributor/regressions.itexi
@@ -183,7 +183,8 @@ than building the source code, as described in
 @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

diff --git a/Documentation/contributor/source-code.itexi b/Documentation/contributor/source-code.itexi
index 97e1025e47bf9f9809207b6d847ab20a84fbd7a8..032bb9b7d4b790833bfbda580966b7c0e0380572 100644 (file)
--- a/Documentation/contributor/source-code.itexi
+++ b/Documentation/contributor/source-code.itexi
@@ -372,7 +372,7 @@ At this stage, don't worry about how many commits you have.
 
 Branches are nerve-wracking until you get used to them.  You can
 save your hard work as individual @file{.patch} files.  Be sure to
-commit your chages first.
+commit your changes first.
 
 @example
 git commit -a
@@ -623,7 +623,7 @@ The @code{translation} branch is a side branch that
 allows translators to work without needing to worry about
 compilation problems.  Periodically, the Translation Meister
 (after verifying that it doesn't break compilation), will
-@emph{merge} this branch back into @code{master} to incorporate
+@emph{merge} this branch into @code{staging} to incorporate
 recent translations.  Similarly, the @code{master} branch is
 usually merged into the @code{translation} branch after
 significant changes to the English documentation.  See
@@ -1020,10 +1020,10 @@ git merge @var{foo}
 If any conflict happens, see @ref{Resolving conflicts}.
 
 There are common usage cases for merging: as a translator, you
-will often want to merge @code{master} into
+will often want the Translations meister to merge @code{master} into
 @code{translation}; on the other hand, the Translations
 meister wants to merge @code{translation} into
-@code{master} whenever he has checked that
+@code{staging} whenever he has checked that
 @code{translation} builds successfully.
 
 
@@ -1321,6 +1321,7 @@ git pull -r
 git cl upload origin/master
 @end example
 
+@c Mention staging here?
 If you have git push ability, make sure that you @emph{remove}
 your patch (with @command{git rebase} or @command{git reset})
 before pushing other stuff.