Add `make-countdown-announcement.sh'.

[lilypond.git] / Documentation / contributor / issues.itexi

diff --git a/Documentation/contributor/issues.itexi b/Documentation/contributor/issues.itexi
index d7c44304f1a4518bccfa68d5d2f163830761271c..8fe73428eefb6b50f452ae211661ee47b77b943c 100644 (file)
--- a/Documentation/contributor/issues.itexi
+++ b/Documentation/contributor/issues.itexi
@@ -186,13 +186,13 @@ the currently-active Bug Squad member(s) can handle the message.
 @subsubheading Daily schedule
 
 @example
-Monday:    Colin H
-Tuesday:   Eluze
-Wednesday: Marek
-Thursday:  Joe
-Friday:    Marek
-Saturday:  Ralph
-Sunday:    Colin H
+Monday:    Eluze
+Tuesday:   Ralph Palmer
+Wednesday: Marek Klein
+Thursday:  Eluze
+Friday:
+Saturday:  Colin Campbell
+Sunday:    Federico Bruni
 @end example
 
 
@@ -830,10 +830,101 @@ separate person handling this task.}
 For contributors/developers: follow the steps in
 @ref{Commits and patches}, and @ref{Pushing to staging}.
 
+@ignore
 For people doing maintenance tasks: git-cl is adding issues, James
 is testing them, Colin is selecting them for countdowns, and
 Patchy is merging from staging to master.  In the coming weeks,
 these tasks will be more and more automated.
+@end ignore
+
+@subheading Patch cycle
+
+@itemize
+
+@item
+Patches get added to the tracker and to Rietveld by the @qq{git-cl} tool, with
+a status of @qq{patch-new}.
+
+@item
+The automated tester, Patchy, verifies that the patch can be applied
+to current master.  By default, it checks that the patch allows @code{make}
+and @code{make test} to complete successfully.  It can also be configured to
+check that @code{make doc} is successful. If it passes, Patchy changes the
+status to @qq{patch-review} and emails the developer list.  If the patch
+fails, Patchy sets it to @qq{patch-needs_work} and notifies the developer list.
+
+@item
+The Patch Meister reviews the tracker periodically, to list patches
+which have been on review for at least 24 hours. The list is found at
+
+@smallexample
+@uref{http://code.google.com/p/lilypond/issues/list?can=2&q=label:patch%20patch=review&sort=modified+patch&colspec=ID%20Type%20Status%20Priority%20Owner%20Patch%20Summary%20Modified}
+@end smallexample
+
+@item
+For each patch, the Handler reviews any discussion on the tracker
+and on Rietveld, to determine whether the patch can go forward.  If
+there is any indication that a developer thinks the patch is not
+ready, the Handler marks it @qq{patch-needs_work} and makes a comment
+regarding the reason, referring to the Rietveld item if needed.
+
+@item
+Patches with explicit approval, or at least no negative comment, can
+be updated to @qq{patch-countdown}.  When saving the tracker item,
+clear the @qq{send email} box to prevent sending notification for
+each patch.
+
+@item
+The Patch Meister sends an email to the developer list, with a fixed
+subject line, to enable filtering by email clients:
+
+@example
+PATCH: Countdown to 20130113
+@end example
+
+The text of the email sets the deadline for this countdown batch.  At
+present, batches are done on Tuesday, Thursday and Sunday evenings.
+
+To create the countdown announcement, use the
+@code{make-countdown-announcement.sh} script, which takes the
+deadline date, and optionally your name.  Follow the instructions
+provided:
+
+@example
+cd $LILYPOND_BUILD_DIR
+../scripts/auxiliar/make-countdown-announcement.sh "Jan 1, 2001" James
+@end example
+
+The script produces an announcement that is easily readable in all
+email clients.  Also, whenever a new contributor submits a patch,
+you will be prompted to add the new username and author name to
+the script itself, and then commit those changes to the main git
+repository.
+
+
+@item
+On the scheduled countdown day, the Patch Meister reviews the
+previous list of patches on countdown, with the same procedure and
+criteria as before.  Patches with no controversy can be set to
+@qq{patch-push} with a courtesy message added to the comment block.
+
+@item
+Roughly at six month intervals, the Patch Meister can list the
+patches which have been set to @qq{patch-needs-work} and send the
+results to the developer list for review.  In most cases, these
+patches should be marked @qq{patch-abandoned} but this should come
+from the developer if possible.
+
+@item
+As in most organisations of unpaid volunteers, fixed procedures are
+useful in as much as they get the job done.  In our community, there
+is room for senior developers to bypass normal patch handling flows,
+particularly now that the testing of patches is largely automated.
+Similarly, the minimum age of 24 hours can reasonably be waived if
+the patch is minor and from an experienced developer.
+
+
+@end itemize
 
 @ignore
 There is a single Patch Meister, and a number of Patch Helpers