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.
Matthias
> -----Ursprüngliche Nachricht-----
> Von: openssl-project <[email protected]> Im Auftrag von Dr.
> Matthias St. Pierre
> Gesendet: Samstag, 26. Oktober 2019 15:40
> An: [email protected]
> 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
>
> https://github.com/openssl/openssl/labels
>
> 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 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] *
