New GitHub labels for pull request and issues - 24 hour grace period

Dr. Matthias St. Pierre Matthias.St.Pierre at
Sat Oct 26 14:07:17 UTC 2019

Note: names might still undergo some fine tuning. For example, 

	[issue: missing documentation]

was just changed to 

	[issue: documentation]

to encompass both missing documentation and errors in documentation.


> -----Ursprüngliche Nachricht-----
> Von: openssl-project <openssl-project-bounces at> Im Auftrag von Dr. Matthias St. Pierre
> Gesendet: Samstag, 26. Oktober 2019 15:40
> An: openssl-project at
> Betreff: New GitHub labels for pull request and issues - 24 hour grace period
> Hi all,
> some of you contributors might have already noticed that the labels which
> are attached to the GitHub pull requests and issues have changed.
> During the face to face meeting it was decided to cleanup some of the
> unused labels and to organize the labelling more systematically to match
> our review and merging process.
> The following gives you a brief outline of the changes. Wordings are mine
> and not authoritative. An official policy update by the OMC will follow.
> It was decided by the OMC that starting from now on all committers need
> to wait for a grace period of (currently) 24 hours after the approval of
> a pull request has completed (which happens when it has the necessary
> number of approvals) before they are allowed to merge the pull request
> to the target branch(es). The two different states are indicated by labels
> ([approval: done] and [ready to merge]). The 24 hour policy will be endorsed
> by a server side git hook and a github bot which which controls the
> [ready to merge] label. There are limited exceptional cases in which a
> committer can manually set the [ready to merge] label to merge earlier.
> (e.g. during the release process).
> Below is a brief overview over the most important new labels. For a full list
> and for explaining comments, see
> Matthias
> --
> *Branch labels*
>     [branch: master]
>     [branch: x.y.z]
> Branch labels serve as indication of all target branches to
> which the pull request is going to be merged. Approval of
> reviewers applies to all target branches, provided the commits
> can be cherry-picked cleanly. If that's not the case, a separate
> pull request needs to be made.
> If there is no branch label, then the github target branch of the
> pull request is assumed. However, in the future we try to be explicit
> by allways adding the target branch (e.g., [branch: master]).
> * Review progress labels*
> 	[approval: review pending]
> 	[approval: omc review pending]
> 	[approval: done]
> 	...24 hour grace period...
> 	[ready to merge]
> * Hold labels*
> Those labels act as blockers and prevent a pull request from
> being merged.
> 	[hold: cla required]      (set by the cla bot, replaces [need-cla], WIP)
> 	[hold: license clash]
> 	[hold: need omc decision]
> * Issue type labels*
> The following labels are going to be set automatically by the issue templates
> (see pull request
> Templates for the starred labels are still to be done.
> 	[issue: bug report]
> 	[issue: feature request]
> 	[issue: missing documentation] *
> 	[issue: question] *

More information about the openssl-project mailing list