New GitHub labels for pull request and issues - 24 hour grace period
Dr. Matthias St. Pierre
Matthias.St.Pierre at ncp-e.com
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
to encompass both missing documentation and errors in documentation.
> -----Ursprüngliche Nachricht-----
> Von: openssl-project <openssl-project-bounces at openssl.org> Im Auftrag von Dr. Matthias St. Pierre
> Gesendet: Samstag, 26. Oktober 2019 15:40
> An: openssl-project at openssl.org
> 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
> *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 https://github.com/openssl/openssl/pull/10266)
> 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