[ << Working with source code ]	[Top][Contents][Index][ ? ]			[ Compiling >> ]
[ < Uploading a patch for review ]		[  Up : Basic Git procedures ]	[ Advanced Git procedures > ]

3.3.7 The patch review cycle

Your patch will be available for reviews for the next few hours or days. Three times a week, patches with no known problems are gathered into a “patch countdown” and their status changed to patch-countdown. The countdown is a 48-hour waiting period in which any final reviews or complaints should be made.

During the countdown, your patch may be set to patch-needs_work, indicating that you should fix something (or at least discuss why the patch needs no modification). If no problems are found, the patch will be set to patch-push.

Once a patch has patch-push, it should be sent to your mentor for uploading. If you have git push ability, look at Pushing to staging.

• Patches get added to the tracker and to Rietveld by the “git-cl” tool, with a status of “patch-new”.
• The automated tester, Patchy, verifies that the patch can be applied to current master. By default, it checks that the patch allows make and make test to complete successfully. It can also be configured to check that make doc is successful. If it passes, Patchy changes the status to “patch-review” and emails the developer list. If the patch fails, Patchy sets it to “patch-needs_work” and notifies the developer list.
• 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

  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

• 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 “patch-needs_work” and makes a comment regarding the reason, referring to the Rietveld item if needed.
• Patches with explicit approval, or at least no negative comment, can be updated to “patch-countdown”. When saving the tracker item, clear the “send email” box to prevent sending notification for each patch.
• The Patch Meister sends an email to the developer list, with a fixed subject line, to enable filtering by email clients:

  PATCH: Countdown to 20130113
  

  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 make-countdown-announcement.sh script, which takes the deadline date, and optionally your name. Follow the instructions provided:

  cd $LILYPOND_GIT
  scripts/auxiliar/make-countdown-announcement.sh "Jan 1, 2001" James
  

  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.

• 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 “patch-push” with a courtesy message added to the comment block.
• Roughly at six month intervals, the Patch Meister can list the patches which have been set to “patch-needs-work” and send the results to the developer list for review. In most cases, these patches should be marked “patch-abandoned” but this should come from the developer if possible.
• 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.

---

[ << Working with source code ]	[Top][Contents][Index][ ? ]			[ Compiling >> ]
[ < Uploading a patch for review ]		[  Up : Basic Git procedures ]	[ Advanced Git procedures > ]

<< Back to Documentation Index

LilyPond — Contributor’s Guide v2.21.0 (development-branch).