X-Git-Url: https://git.donarmstrong.com/?a=blobdiff_plain;f=Documentation%2Fcontributor%2Fintroduction.itexi;h=59eb050c1a2b59e38b3a33f64e6ffbb867fea71b;hb=da68c81eba74d8a968e0599e7de6c363f84ed3d8;hp=0883a1a81603c9f987823905c3a043f261b7bc3d;hpb=46e296f5381495ce30108aa981e549d61e55a009;p=lilypond.git diff --git a/Documentation/contributor/introduction.itexi b/Documentation/contributor/introduction.itexi index 0883a1a816..59eb050c1a 100644 --- a/Documentation/contributor/introduction.itexi +++ b/Documentation/contributor/introduction.itexi @@ -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}: @@ -146,17 +147,15 @@ after finishing work on a patch or branch: @enumerate @item -upload it with our custom @code{git-cl}. In addition to uploading -it to the google rietveld code review tool, this adds a tracker -issue so that we don't lose your patch. The @qq{status} of your -patch is kept on the issue tracker; see @ref{Issues}. - -@example -@uref{https://github.com/gperciva/git-cl} -@end example +upload it with our custom @code{git-cl} @q{helper-script}; see +@ref{git-cl}. In addition to uploading patches to the Google's Rietveld +Code Review Tool the script will also update the issue tracker (or add a +new issue as appropriate) so that we don't lose reference to your +patch. The @qq{status} of your patch is kept on the issue tracker; +see @ref{Issues}. -Your patch will be given @code{Patch-new} status. More info in -@ref{Uploading a patch for review}. +Your patch will be given @code{Patch-new} status. More information on +this can be found in the section @ref{Uploading a patch for review}. @item If your patch passes some automatic tests, it will be given @@ -165,13 +164,11 @@ hours. @item After that, the patch must wait for the next @qq{patch countdown}, -which occur 3 times a week. If there are a lot of patches waiting -for a countdown, a subset of patches are chosen randomly. When -your patch is put on a countdown, it will be given -@code{Patch-countdown} status. +which occurs roughly every 3 days. When 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 one +The countdown is a 72-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. @@ -188,20 +185,6 @@ given our limited resources for reviewing patches and a history of unintended breakage in @code{master}, this is the best compromise we have found.} -@c I don't think this is important enough to list here, but I may -@c change my mind and/or leave a link to a later CG section. -@ignore -@item @strong{code style}: -C++ code should be formatted with -@file{scripts/auxiliar/fixcc.py}, which requires -@url{http://astyle.sourceforge.net/, astyle 2.02}. However, we -are not very strict about this requirement. - -At the moment, scheme code should be formatted @qq{like emacs does -it}. We are working on an automated tool to simplify this step. -However, we are not very strict about this requirement either. -@end ignore - @end itemize @@ -279,8 +262,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).