Hey folks, We’re in the final stage of bringing up support for GitHub pull-requests. To support this effort, we’re starting to add labels to our project. We intend to use labels as a replacement for commit-queue flags and Product/Component/Version fields in bugzilla. Before our tools are too reliant on specific label names, we wanted to solicit feedback to see if folks had specific opinions on certain categories. Bellow I have some preliminary thoughts on what labels the project would find helpful: EWS and Merge-Queue labels: merge-queue (green): Applied to send a PR to merge-queue (equivalent of a modern cq+) fast-merge-queue (green): Applied to send a PR to merge-queue, but skip building and testing merging-blocked (purple): Applied to prevent a change from being merged (equivalent of a modern cq-) Component labels (all white) Use our existing bugzilla component labels and descriptions Version labels (all grey) Use our existing bugzilla version labels and descriptions Misc: regression (red): Addresses a problem that did not previously exist It’s worth noting that changing a labels name does apply to existing labels of that name, so any decisions we make now can be modified without too much disruption. Existing labels: https://github.com/WebKit/WebKit/labels <https://github.com/WebKit/WebKit/labels> Excited to here your thoughts, Jonathan
On Thu, Mar 10, 2022 at 10:49 AM Jonathan Bedard via webkit-dev < webkit-dev@lists.webkit.org> wrote:
Hey folks,
We’re in the final stage of bringing up support for GitHub pull-requests. To support this effort, we’re starting to add labels to our project. We intend to use labels as a replacement for commit-queue flags and Product/Component/Version fields in bugzilla. Before our tools are too reliant on specific label names, we wanted to solicit feedback to see if folks had specific opinions on certain categories. Bellow I have some preliminary thoughts on what labels the project would find helpful:
EWS and Merge-Queue labels: merge-queue (green): Applied to send a PR to merge-queue (equivalent of a modern cq+) fast-merge-queue (green): Applied to send a PR to merge-queue, but skip building and testing
I don't like "fast merge" because who doesn't want fast merging? It doesn't convey why that's different from regular merge, or why using this option may not be always desirable. I also don't think "queue" adds much information about these flags. So why not simply: - merge - untested-merge or testless-merge? - R. Niwa
participants (2)
-
Jonathan Bedard
-
Ryosuke Niwa