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

3.2.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 Merging to master.

• Patches get added by opening a merge request. A bot automatically adds the Patch::new label to it.
• GitLab triggers automated testing which ensures that the patch completes make, make test, and make doc. Afterwards, the Patch Meister manually runs make check to verify regression tests. If both steps pass, the merge request is labelled Patch::review. On failure, the status is updated to Patch::needs_work.
• 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

  https://gitlab.com/lilypond/lilypond/-/merge_requests?label_name[]=Patch%3A%3Areview

• For each patch, the Handler reviews any discussion on the merge request, 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 comment 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.

• 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]	[ Compiling >> ]
[ < Uploading a patch for review ]	[ Up : Basic Git procedures ]	[ Advanced Git procedures > ]

<< Back to Documentation Index

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