X-Git-Url: https://git.donarmstrong.com/?a=blobdiff_plain;f=Documentation%2Fcontributor%2Fintroduction.itexi;h=b0948bafe15d853ce8eb9879839a277d828223ad;hb=fa038b9595a1578f62430d8ed41bf2bbba8116e9;hp=914e7ef72b09ab8884a70284fdf6d1ad044031f3;hpb=a5be31d893c3a738d87d07d18d6db8fa725e8efc;p=lilypond.git

diff --git a/Documentation/contributor/introduction.itexi b/Documentation/contributor/introduction.itexi
index 914e7ef72b..b0948bafe1 100644
--- a/Documentation/contributor/introduction.itexi
+++ b/Documentation/contributor/introduction.itexi
@@ -21,9 +21,9 @@ help LilyPond.
 
 @helpusNeed
 
-@helpusTasks
+@helpusSimple
 
-@helpusProjects
+@helpusAdvanced
 
 
 @node Overview of work flow
@@ -47,27 +47,24 @@ since the program was born.
 
 The @q{official} LilyPond Git repository is hosted by the GNU
 Savannah software forge at @uref{http://git.sv.gnu.org}.
-Although, since Git uses a @emph{distributed} model, technically
-there is no central repository.  Instead, each contributor keeps a
-complete copy of the entire repository (about 116MB).
 
 Changes made within one contributor's copy of the repository can
 be shared with other contributors using @emph{patches}.  A patch
-is a simple text file generated by the @command{git} program that
-indicates what changes have been made (using a special format).
+is a text file that indicates what changes have been made.
 If a contributor's patch is approved for inclusion (usually
 through the mailing list), someone on the current development team
 will @emph{push} the patch to the official repository.
 
 The Savannah software forge provides two separate interfaces for
-viewing the LilyPond Git repository online: @emph{cgit} and
-@emph{gitweb}.  The cgit interface should work faster than gitweb
+viewing the LilyPond Git repository online:
+@uref{http://git.sv.gnu.org/cgit/lilypond.git/, cgit} and
+@uref{http://git.sv.gnu.org/gitweb/?p=lilypond.git, gitweb}.
+
+@ignore
+The cgit interface should work faster than gitweb
 in most situations, but only gitweb allows you to search through
 the source code using @command{grep}, which you may find useful.
-The cgit interface is at
-@uref{http://git.sv.gnu.org/cgit/lilypond.git/} and the gitweb
-interface is at
-@uref{http://git.sv.gnu.org/gitweb/?p=lilypond.git}.
+@end ignore
 
 Git is a complex and powerful tool, but tends to be confusing at
 first, particularly for users not familiar with the command line
@@ -94,7 +91,7 @@ the developers' mailing list here:
 @uref{http://lists.gnu.org/mailman/listinfo/lilypond-devel}.
 
 @warning{Contributors on Windows or MacOS X wishing to compile
-code or documentation are strongly advised to use our Ubuntu
+code or documentation are strongly advised to use our Debian
 LilyPond Developer Remix, as discussed in @ref{Quick start}.}
 
 
@@ -112,8 +109,12 @@ hosted by GNU savannah.
 @uref{http://git.savannah.gnu.org/gitweb/?p=lilypond.git}
 @end example
 
+@item @strong{environment variables}:
+many maintenance scripts, and many instructions in this guide rely on
+predefined @ref{Environment variables}.
+
 @item @strong{mailing lists}:
-given on @rweb{Contacts}.
+given on @rweb{Contact}.
 
 @item @strong{branches}:
 
@@ -124,7 +125,7 @@ base your work from this, but do @strong{not push} to it.
 @item @code{staging}:
 after a successful review (see below), push here.
 
-@item @code{lilypond/translation}:
+@item @code{translation}:
 translators should base their work from this, and also push to it.
 
 @item @code{dev/foo}:
@@ -171,9 +172,9 @@ your patch is put on a countdown, it will be given
 @code{Patch-countdown} status.
 
 @item
-The countdown is a 48-hour period which gives other developers a
-chance to review the patch.  If no significant problems are found,
-your patch will be given @code{Patch-push} status.
+The countdown is a 48-hour period which gives other developers one
+last chance to review the patch.  If no significant problems are
+found, your patch will be given @code{Patch-push} status.
 
 @item
 You may now either push it to the @code{staging} branch, or email
@@ -183,7 +184,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.}
@@ -279,8 +280,8 @@ switching git branches (not expected, but just in case...)
 @item
 You don't need to be able to completely approve patches.  Make
 sure the patch meets whatever you know of the guidelines (for doc
-style, code indentation, whatever), and then send it on to the
-frog list or -devel for more comments.  If you feel confident
+style, code indentation, whatever), and then send it on to -devel
+for more comments.  If you feel confident
 about the patch, you can push it directly (this is mainly intended
 for docs and translations; code patches should almost always go to
 -devel before being pushed).