From f2ea0cc22595ff51942ed5010ec529e8d2fb76ad Mon Sep 17 00:00:00 2001 From: Francisco Vila Date: Thu, 26 Apr 2012 11:54:59 +0200 Subject: [PATCH] CG: change some references from master to staging. --- Documentation/contributor/doc-work.itexi | 45 +++++++++++++------- Documentation/contributor/introduction.itexi | 2 +- Documentation/contributor/regressions.itexi | 3 +- Documentation/contributor/source-code.itexi | 9 ++-- 4 files changed, 37 insertions(+), 22 deletions(-) diff --git a/Documentation/contributor/doc-work.itexi b/Documentation/contributor/doc-work.itexi index dabb13beb4..cdf0e26f8d 100644 --- 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 bb0f984935..0883a1a816 100644 --- 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 a5dac48226..5de3f8aa91 100644 --- 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 97e1025e47..032bb9b7d4 100644 --- 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. -- 2.39.2