| [ << Working with source code ] | [Top][Contents] | [ Compiling >> ] |
| [ < Automated testing ] | [ Up : Lifecycle of a merge request ] | [ Merging to master > ] |
3.3.3 Patch countdown
The Patch Meister is the person who advances patches in the countdown process based on review comments.
Note: The Patch Meister’s role is a purely administrative one and no programming skill or judgement is assumed or required.
The current Patch Meister is Colin Campbell cpkc.music@shaw.ca.
The Patch Meister reviews the tracker periodically, to list patches
which have been on review for at least 24 hours. 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, are
updated to Patch::countdown. The countdown is a 48-hour waiting
period in which any final reviews or complaints should be made.
The Patch Meister sends an email to the developer list. The subject line has a fixed formatting, to enable filtering by email clients, like so:
PATCHES: Countdown for February 30th
The text of the email sets the deadline for this countdown batch. At present, batches are done on Tuesday, Thursday and Sunday evenings.
At the next countdown, if no problems were found, the patch will be
set to Patch::push. New contributors should ask for it to be
merged. Developers merge their patches themselves, see Merging to master and Commit access.
Alternately, 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). It also happens that patches waiting
for minor fixes are put on countdown a second time.
Successive revisions are made in response to comments are uploaded by pushing to the same branch. GitLab automatically keeps track of all pushed commits and allows to compare revisions with each other.
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 >> ] |
| [ < Automated testing ] | [ Up : Lifecycle of a merge request ] | [ Merging to master > ] |