slachiewicz opened a new issue, #304: URL: https://github.com/apache/maven-gh-actions-shared/issues/304
Sixteen labels across eleven repositories answer the same question — which release line does this change concern — in four different vocabularies: | vocabulary | repositories | uses | |---|---|---| | `mvn3` | maven, maven-wagon, maven-filtering, maven-site-plugin | 365 | | `3.x` | maven-plugin-tools, maven-compiler-plugin, maven-resources-plugin, maven-plugin-testing | 174 | | `mvn4` / `mvn40` | maven | 426 | | `backport` | maven, maven-mvnd, maven-filtering, maven-plugin-tools | 359 | | `master` | maven-surefire | 19 | | `resolver1` | maven-resolver | 97 | **1440 applications, and fifteen of the sixteen labels have no description at all** — so the only way to learn what one means is to look at what it has been used on. ## Why this is worth fixing Two of these are actively misleading rather than merely untidy. **`backport` means opposite things.** It is documented in `maven-mvnd` as *"backport to a maintenance branch"* — work still owed — and undocumented in the other three. That same word splits both ways across the ASF: Kafka's `backport-candidate` is *"a candidate to be backported"*, while Hadoop's and DataFusion's `backport` mean *"this PR is itself a backport"*. A reviewer cannot tell which we mean. **`master` in maven-surefire** reads like the opposite of a backport while apparently meaning much the same thing. And none of the four can express **"affects both 3.x and 4.x"**, which for a project running two live lines is the normal case rather than an edge case. ## Proposal | label | meaning | |---|---| | `affects:3.x` | Applies to the Maven 3 line | | `affects:4.x` | Applies to the Maven 4 line | | `needs-backport` | Merged on the main line, still owed to a maintenance branch | A prefix, matching the `priority:` family already in `labels.js`. Both `affects:` labels can apply at once, which is the case none of the current four covers. `needs-backport` states an obligation rather than a location, so it can be checked and cleared — precisely the ambiguity that bites Kafka and Hadoop. And it names the line rather than the branch, so it survives 3.10 becoming 3.11. This is not invented. Of the forty most-starred non-archived `apache/*` repositories, **seven use an obligation-shaped backport label**. The alternatives in use elsewhere are Flink's `target:release-1.20` style (intent) and Pulsar's `cherry-picked/branch-4.2` style (state), if either is preferred. `maven-resolver`'s `resolver1` would stay as it is — Resolver versions its API on a different axis, and folding it in would conflate two things. ## What this does not change Release notes already separate the lines, and do not use labels to do it: `filter-by-commitish`, a drafter per branch, and milestones carrying a `branch: <name>` description that the automation matches on. None of that would be touched. These labels do a different job — signalling on an **open** issue or pull request which lines are affected, before anything is merged and before a milestone exists. ## Cost About 1440 items to relabel, which is scriptable, plus deleting the old labels afterwards so they stop reappearing. I am happy to do that work and would post the script here before running it against anything. Worth knowing up front: release-drafter's autolabeler matches on head branch, title, body and changed files, but **not** on the base branch — so the obvious rule, *"a PR targeting `maven-3.10.x` gets `affects:3.x`"*, cannot be automated that way. These would stay hand-applied, as they are today. ## Questions 1. Does the `affects:` / `needs-backport` shape look right, or would Flink's `target:release-x.y` or Pulsar's `cherry-picked/branch-x.y` be preferred? 2. Is there a reason `maven-resolver` or `maven-mvnd` should keep their own vocabularies rather than join in? --- Context, not part of this question — the surrounding label cleanup is already in flight: #301 gave `labels.js` consistent colours and descriptions, #302 made label creation opt-in and added a monthly drift report, and #303 removes ten labels the release-drafter config referenced that exist in no repository at all. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
