There are a lot of things that come to my mind when I see all those labels:
IMHO there are too many of them and for some of them the precise meaning is not clear. So maybe we should reduce their number a bit and document the meaning and semantics of the other. I) NAMING CONVENTIONS First of all: Labels should be short and lowercase. Personally, I like these lisp-style identifiers like 'need-cla' and 'technical-debt'. So I would rename 'pending 2nd review' -> 'review-required' 'Issue resolved - WONTFIX' -> 'wont-fix' A propos: it might be useful to split the 'pending 2nd review' into two different labels (of the same color): 'pending 2nd review' -> 'review-required' and 'omc-review-required' II) UNUSED LABELS 'wont-fix' and 'technical-debt' are currently unused. Do we really need them? For example, if an issue is closed without fixing it, does it really require a ‚wont-fix‘ label? III) VERSION NUMBER LABELS It seems like the version number labels '1.0.2', '1.1.0', '1.1.1', 'after 1.1.1' currently serve two differente purposes: 1. Indicate the intention to which branches a pull request will be backported Approval holds for all labeled branches. 2. As surrogate milestones ad 1): Using the version number labels as indication of merge intention makes sense. But then the 'master' label and (currently) the '1.1.1' label are superfluous. If the pull request targets the 'master' branch, why does it need a 'master' label? The github search index allows to search for 'base:<branchname>' which is a much more reliable way of determining the target branch: Open pull requests targeting 'master': https://github.com/openssl/openssl/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+base%3Amaster Open pull requests targeting 'OpenSSL_1_1_0-stable': https://github.com/openssl/openssl/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+base%3AOpenSSL_1_1_0-stable If you follow the second link, you will immediately find #5260 which targets OpenSSL_1_1_0-stable but is erroneously labeled with 'post 1.1.1'. So IMHO it only makes sense to set labels for stable branches to which one intents to backport. This means that 'master' and (currently) '1.1.1' are superfluous. ad 2): The label 'after 1.1.1' is a surrogate milestone and IMHO it would be better to use the 'Post 1.1.1' milestone instead of the label. One could go even further and ask what sense does it make to have such an unspecific milestone as 'Post 1.1.1'? Wouldn't it be better to leave such pull requests unassigned? Maybe one reason for having the 'after 1.1.1' label is that these pull requests can't be merged yet, since 1.1.1 has not been split off as a separate branch yet. But isn't the 'hold' label intended for precisely this case? Or will it be set only if an omc member places a veto and requests a vote? The latter could be named 'vote-requested'. IMHO it would make sense to use the version labels only to indicate merge intention and otherwise use milestones. https://github.com/openssl/openssl/labels https://github.com/openssl/openssl/milestones Regards, Matthias _______________________________________________ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project