@menu
* Meta-policy for this document::
+* Environment variables::
* Meisters::
+* Patchy::
* Administrative mailing list::
* Grand Organization Project (GOP)::
* Grand LilyPond Input Syntax Standardization (GLISS)::
@end itemize
+@node Environment variables
+@section Environment variables
+
+Some maintenance scripts and instructions in this guide rely on
+the following environment variables. They should be predefined in
+LilyDev distribution (see @ref{LilyDev}); if you set up your own
+development environment, you can set them by appending these settings to
+your @file{~/.bashrc} (or whatever defines your default environment
+variables for the user account for LilyPond development), then logging
+out and in (adapt directories to your setup):
+
+@example
+LILYPOND_GIT=~/lilypond-git
+export LILYPOND_GIT
+LILYPOND_BUILD_DIR=~/lilypond-git/build
+export LILYPOND_BUILD_DIR
+@end example
+
+The standard build and install procedure (with @code{autogen.sh},
+@code{configure}, @code{make}, @code{make install}, @code{make doc}
+@dots{}) does not rely on them.
+
+In addition, for working on the website, @code{LILYPOND_WEB_MEDIA_GIT}
+should be set to the repository lilypond-extra, see
+@ref{lilypond-extra}.
+
@node Meisters
@section Meisters
on which part of their job, checks to make sure that everything is
running smoothly, and has final say on our policy for Issues.
-Currently: Phil
+Currently: Colin H
@item
Doc Meister: trains new doc editors/writers, organizes who works
@w{@code{-devel}} community into actually reviewing said patches, and
finally pushes the patches once they're accepted. This person is
@emph{not} responsible for training new programmers, because that
-would be far too much work -- he job is @qq{only} to guide
+would be far too much work -- his/her job is @qq{only} to guide
completed patches through our process.
-Currently: Carl
+Currently: Mike Solomon
@end itemize
+@node Patchy
+@section Patchy
+
+@subheading Introduction
+
+Patchy is a set of Python scripts to automate two administrative
+tasks:
+
+@itemize
+@item
+@code{lilypond-patchy-staging.py}: checks that new commits in
+@code{staging} can compile the regtests and documentation before
+merging @code{staging} into @code{master}.
+
+(completely automatic)
+
+@item
+@code{test-patches.py}: checks that patches apply to Git @code{master},
+compile, and lets a human check that there are no big unintended
+changes to the regtests.
+
+(requires some human input)
+
+@end itemize
+
+@subheading Installing Patchy
+
+To install Patchy, you should do the following:
+
+@enumerate
+@item
+Create a new user on your box to run Patchy; this is a security
+step for your own protection. It is recommended that this should
+not be an administrator. New users are created from System;
+Administration; Users and Groups.
+
+@item
+Get the Patchy scripts from
+@example
+@uref{https://github.com/gperciva/lilypond-extra/}
+@end example
+Patchy is in the @file{patches/} directory.
+
+@item
+Put the scripts and Python libraries contained in @file{patches} in a
+sensible place on your system; this can be done by appending
+@file{patches/} full path to the @var{PATH} of the user that runs
+Patchy.
+
+@item
+Create a new git repository with
+@example
+git clone git://git.sv.gnu.org/lilypond.git
+@end example
+This will create a directory called lilypond with the repo in it.
+Make sure it's where you want it and name it lilypond-git
+(assuming you want to follow the standard naming conventions).
+
+@item
+Create environment variables @var{LILYPOND_GIT} and
+@var{LILYPOND_BUILD_DIR}, see @ref{Environment variables}.
+
+@item
+Run Patchy once to set up config files, answer @q{@code{n}} when it
+asks for going on, unless the default config file happens to suit your
+setup:
+@example
+lilypond-patchy-staging.py
+@end example
+
+@item
+Edit @file{$HOME/.lilypond-patchy-config} to provide the location of
+your local lilypond Git repository, working directories for your build
+directory, your results directory, compiler options and notification
+method. If you don't want to use email notification, then delete
+everything after @code{smtp_command:}.
+
+@item
+Ensure that your new user has git push access. Follow the
+instructions in the CG at @ref{Commit access}. Do not set
+password protection for the key --- if you do you will not be able
+to run patchy unattended.
+
+@end enumerate
+
+@subheading lilypond-patchy-staging.py
+
+@code{lilypond-patchy-staging.py} is run with
+@example
+python lilypond-patchy-staging.py
+@end example
+Not much appears to happen except you can see a lot of CPU gets used
+if you open System Monitor. There's not much point running
+@code{lilypond-patchy-staging.py} unless there is something in
+@code{staging} to be merged to @code{master}, however, if there's
+nothing new in @code{staging} then the script won't waste resources by
+compiling anything.
+
+The script fetches the current patches in staging and runs
+@code{make}, @code{make test} and @code{make doc} to ensure that all of
+these complete error-free. If you have set Patchy up to use email,
+it emails its results to you. If you haven't, then you can view
+them in a logfile. It also merges @code{staging} into @code{master}.
+
+@warning{in case the build fails, do not try to push fixes on top of
+staging branch, for details see @ref{Pushing to staging}.}
+
+When you have run Patchy a few successful times with email sending,
+you are ready for running it as a cron job. First, make sure you have
+the following in @file{$HOME/.lilypond-patchy-config} to avoid
+email flood:
+
+@example
+[notification]
+notify_non_action = no
+@end example
+
+Then, assuming Patchy run with user account @code{patchy}, write the
+following to @file{$HOME/lilypond-patchy.cron}, adapting it as
+necessary (the @code{/2} means @qq{run this every 2 hours}):
+@example
+02 0-23/2 * * * /home/patchy/git/lilypond-extra/patches/lilypond-patchy-staging.py
+@end example
+
+@warning{@code{cron} will not inherit environment variables from
+your main setup, so you must re-define any variables inside
+@file{$HOME/lilypond-patchy.cron}. For instance, @var{LILYPOND_GIT}
+may need to be defined if @var{git_repository_dir} is not correctly
+set in @file{$HOME/.lilypond-patchy-config}.}
+
+Finally, install the cron job (you may need superuser privileges for
+this):
+@example
+crontab -u patchy /home/patchy/lilypond-patchy.cron
+@end example
+
+@subheading test-patches.py
+@code{test-patches.py} prepares a regtest comparison for a human to
+quickly glance at, to determine if the patch is ready for a review.
+After looking at the comparison (or the lack of a comparison in the
+case of problems), run @code{accept-patch.py} or
+@code{reject-patch.py}.
+
+Once a patch has gotten a "LGTM" from Patchy, it should be
+reviewed by relevant developers, and if it passes this, it can be
+considered for countdown (see @ref{Commits and patches}) and
+pushing to staging (see @ref{Pushing to staging}).
+
+
@node Administrative mailing list
@section Administrative mailing list
-An mailing list for administrative issues is maintained at
+A mailing list for administrative issues is maintained at
@code{lilypond-hackers@@gnu.org}.
This list is intended to be used for discussions that should be kept
@itemize
@item
-Clarify the various development tasks by writing down the polices
+Clarify the various development tasks by writing down the policies
and techniques and/or simplifying the tasks directly.
@item
code.
Having 1 more normal user answering emails on lilypond-user won't
-have a dramatic trick-up affect all by himself, of course. But if
+have a dramatic @q{trickle-up} effect all by itself, of course. But if
we had 8 users volunteering to answer emails, 6 users starting to
write documentation, and 2 users editing LSR... well, that would
free up a lot of current bug-fixing-capable contributors to focus
Although GOP is a short-term project, the main goal is to train
more people to handle ongoing jobs. The more people doing these
-jobs, the ligher the work will be, and the more we can get done
+jobs, the lighter the work will be, and the more we can get done
with lilypond!
Also, it would be nice if we had at least one "replacement" /
documentation. It would be great if somebody could create
properly-formatted patches for these corrections.
-Technical requirements: ability to run @ref{Lilydev}.
+Technical requirements: ability to run @ref{LilyDev}.
@item LSR editor:
LSR contains many useful examples of lilypond, but some snippets
often find them in Ponds of Lilies) and new feature implementors.
Technical requirements: development environment (such as
-@ref{Lilydev}), ability to read+write scheme and/or C++ code.
+@ref{LilyDev}), ability to read+write scheme and/or C++ code.
@end itemize
(prep: 2 hours. discuss: 10 hours)
-@item @strong{Future release policy}:
-(how) should we change any policies pertaining to releases? Should
-an undocumented new feature count as release-blocking?
-
-(prep: 1 hour. discuss: 15 hours)
-
-@item @strong{lilypond-hackers mailing list}:
-Should we have a private mailing list for senior developers? If
-so, who should be on it?
-
-(prep: 2 hours+3 weeks. discuss: 10 hours)
-
-@item @strong{Hackers B}:
-
-
-@item @strong{Git repository(s)}:
-We currently have a web/ branch in our main repo; this seems
-misleading to new developers. More generally, should we have
-branches that aren't related to the master? i.e. should we
-restrict a git branch to code which is an actual "branch" of
-development? Also, some of our code (notably the windows and osx
-lilypad) isn't in a git repository at all.
-We can add new repositories very easily; should make repositories
-like
-@example
-git://git.sv.gnu.org/lilypond/gub.git
-git://git.sv.gnu.org/lilypond/lilypad.git
-git://git.sv.gnu.org/lilypond/misc.git
-@end example
-? More information here:
-@uref{http://code.google.com/p/lilypond/issues/detail?id=980}
-
-(prep: 2 hours. discuss: 10 hours)
-
-@item @strong{Roadmap of future development}:
-Many projects have a roadmap of planned (or desired) future work.
-Should we use one? If so, what should go on it, bearing in mind
-our volunteer status? Is there any way of having a roadmap that
-isn't vaporware?
-
-(prep: 1 hour. discuss: 5 hours)
-
@item @strong{Official links to other organizations?}:
There's something called the "software freedom conservancy", and
in general, there's a bunch of "umbrella organizations". Joining
(prep: 2 hours. discuss: 5 hours)
-@item @strong{Mailing lists}:
-We currently have a mix of official GNU mailing lists and lilynet
-lists. Is there a strong rationale for having separate mailing
-list servers? Why not pick one place, and put all our lists there?
-(or at least, all "permanent" lists?)
-
-(prep: 1 hour. discuss: 5 hours)
-
@item @strong{Issue tracking with google code}:
We use the google issue tracker, but this means that we are
relying on a commercial entity for a large part of our
(prep: 5 hours. discuss: 15 hours)
-@item @strong{Subdomains of *.lilypond.org}:
-Unless Jan has a really weird DNS hosting setup, there are no
-technical barriers to having names like lsr.lilypond.org,
-frog.lilypond.org, or news.lilypond.org. Is this something that we
-want to do?
-
-(prep: 1 hours+2 weeks. discuss: 5 hours)
-
-@item @strong{Authorship in source files}:
-Our documentation currently does not attempt to track individual
-authors of each file, while our source code makes a confused and
-jumbled attempt to track this. A number of guidelines for F/OSS
-projects explicitly recommends _not_ tracking this in individual
-files, since the code repository will track that for you.
-
-(prep: 2 hours. discuss: 15 hours)
-
@item @strong{Clarity for sponsorships}:
We currently do not advertize bounties and sponsorships on the
webpage. How much advertising do we want, and what type?
(prep: 2 hours. discuss: 10 hours)
-@item @strong{Separate branches for active development}:
-it might be good to have @emph{everybody} working on separate
-branches. This complicates the git setup, but with sufficient
-logic in lily-git.tcl, we can probably make it transparent to
-newbies. However, we'd need a reliable person to handle all the
-required merging and stuff.
-
-(prep: 2 hours. discuss: 10 hours)
-
-@item @strong{When do we add regtests?}:
-There is a discrepancy between our stated policy on adding
-regtests, and our actual practice in handling bugs and patches.
-Clarify.
-
-There is also a wider question how to organize the regtests, such
-as where to put interesting-console-output regtests, including
-stuff like lilypond-book and midi2ly in a sensible manner, and
-possibly including regtests for currently-broken functionality.
-
-(prep: 2 hours. discuss: 5 hours)
-
@item @strong{code readability}:
"Our aim when producing source code for Lilypond in whatever
language is that it should be totally comprehensible to a
@item
anything which stops contributors from helping out (e.g.
lily-git.tcl not working, source tree(s) not being available,
-lilydev being unable to compile git master, inaccurate
+LilyDev being unable to compile git master, inaccurate
instructions in the Contributor's Guide 2 Quick start).
To limit this scope of this point, we will assume that the
-contributor is using the latest lilydev and has read the relevant
+contributor is using the latest LilyDev and has read the relevant
part(s) of the Contributor's Guide. Problems in other chapters of
the CG are not sufficient to qualify as Type-Critical.
is strictly additional to the log files.
@item
-Logfiles from calling lilypond (as part of lilypond-book) will go
-in the relevant @file{build/out/lybook-db/12/lily-123456.log}
-file. All other logfiles will go in the @file{build/logfiles/}
+Logfiles from calling lilypond (as part of lilypond-book) will go in
+the relevant
+@file{$LILYPOND_BUILD_DIR/out/lybook-db/12/lily-123456.log} file. All
+other logfiles will go in the @file{$LILYPOND_BUILD_DIR/logfiles/}
directory.
A single @code{make doc} will therefore result in hundreds of log
projects / lilypond.git / blobdiff