Merge remote-tracking branch 'origin/stable/2.16' into translation

[lilypond.git] / Documentation / contributor / source-code.itexi

diff --git a/Documentation/contributor/source-code.itexi b/Documentation/contributor/source-code.itexi
index 97e1025e47bf9f9809207b6d847ab20a84fbd7a8..d3f4f3a11b8dc11e7813f658d286606a46d97c27 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
@@ -549,7 +549,7 @@ environment variable to point to that repository.
 @end example
 
 To configure an environment variable in bash (the default for most
-Linux distributions),
+GNU/Linux distributions),
 
 @example
 export LILYPOND_WEB_MEDIA_GIT=$HOME/dir/of/lilypond-extra/
@@ -559,18 +559,23 @@ export LILYPOND_WEB_MEDIA_GIT=$HOME/dir/of/lilypond-extra/
 @unnumberedsubsubsec Grand Unified Builder (GUB)
 
 Another item of interest might be the Grand Unified Builder, our
-cross-platform building tool.  Since it is used by projects as
+cross-platform building tool.  Since it is used by other projects as
 well, it is not stored in our gub repository.  For more info, see
 @uref{http://lilypond.org/gub}.
 
-There are two locations for this repository, which will hopefully
-be kept up-to-date with each other:
+There are two locations for this repository: the version being used to
+build lilypond, which is at
 
 @example
-@uref{http://github.com/janneke/gub}
 @uref{http://github.com/gperciva/gub}
 @end example
 
+and the original version by Jan Nieuwenhuizen, kept at
+
+@example
+@uref{http://github.com/janneke/gub}
+@end example
+
 
 @node lilypad
 @unnumberedsubsubsec lilypad
@@ -623,7 +628,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
@@ -1019,12 +1024,11 @@ 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
-@code{translation}; on the other hand, the Translations
-meister wants to merge @code{translation} into
-@code{master} whenever he has checked that
-@code{translation} builds successfully.
+There are common usage cases for merging: as a translator, you 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{staging} whenever he has
+checked that @code{translation} builds successfully.
 
 
 @node Commits and patches
@@ -1321,6 +1325,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.
@@ -2039,6 +2044,15 @@ patch has been lost.  Note that you can check the commits on
 @code{origin/staging} by looking at the git web interface on
 savannah.
 
+It may happen occasionally that the staging branch breaks automated
+testing.  In this case the automatic move of staging material to
+master gets halted in order to avoid broken material entering master.
+This is a safety net.  Please do not try breaking out from it by
+adding fixes on top of staging: in that case the whole sequence will
+end up in master after all, defeating the purpose of the system.  The
+proper fix usually involves rewriting the staging branch and is best
+left to core developers after discussion on the developer list.
+
 @subsubheading If your work is in a patch file
 
 Assuming that your patch is in a file called