doc: describe labelling process for backports #12431
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -80,6 +80,33 @@ Please use these when possible / appropriate | |
| git checkout $(git show -s --pretty='%T' $(git show-ref -d $(git describe --abbrev=0) | tail -n1 | awk '{print $1}')) -- test; make -j4 test | ||
| ``` | ||
|
|
||
| ### LTS/Version labels | ||
|
|
||
| We use labels to keep track of which branches a commit should land on: | ||
|
|
||
| * `dont-land-on-v?.x` | ||
| * For changes that do not apply to a certain release line | ||
| * Also used when the work of backporting a change outweighs the benefits | ||
| * `land-on-v?.x` | ||
|
There was a problem hiding this comment. should we consider changing this to There was a problem hiding this comment. If its only applied after the picking occurs, and only for cherry-picked (aka "not backported"), then SGTM There was a problem hiding this comment. What Sam said, if that's how it'll be used, it's a more descriptive/specific tag, so +1. |
||
| * Used by releasers to mark a PR as scheduled for inclusion in an LTS release | ||
| * Applied to the original PR for clean cherry-picks, to the backport PR otherwise | ||
| * `backport-requested-v?.x` | ||
|
There was a problem hiding this comment. Should we apply it to things, like a test change, that we would be willing to land if had a backport? Or reserve it for things like bug fixes that we actually want to be backported, but that aren't landing? There was a problem hiding this comment. for example: #12599 would be worth having on 6.x, just to keep the code synced, but if the author doesn't want to backport, that's OK |
||
| * Used to indicate that a PR needs a manual backport to a branch in order to land the changes on that branch | ||
| * Typically applied by a releaser when the PR does not apply cleanly or it breaks the tests after applying | ||
| * Will be replaced by either `dont-land-on-v?.x` or `backported-to-v?.x` | ||
| * `backported-to-v?.x` | ||
| * Applied to PRs for which a backport PR has been merged | ||
| * `lts-watch-v?.x` | ||
| * Applied to PRs which the LTS working group should consider including in a LTS release | ||
| * Does not indicate that any specific action will be taken, but can be effective as messaging to non-collaborators | ||
| * `lts-agenda` | ||
| * For things that need discussion by the LTS working group | ||
| * (for example semver-minor changes that need or should go into an LTS release) | ||
| * `v?.x` | ||
| * Automatically applied to changes that do not target `master` but rather the `v?.x-staging` branch | ||
|
|
||
| Once a release line enters maintenance mode, the corresponding labels do not | ||
| need to be attached anymore, as only important bugfixes will be included. | ||
|
|
||
| ### Other Labels | ||
|
|
||
|
|
@@ -89,10 +116,6 @@ Please use these when possible / appropriate | |
| * Architecture labels | ||
| * `arm`, `mips`, `s390`, `ppc` | ||
| * No x86{_64}, since that is the implied default | ||
|
|
||
|
|
||
| ## Updating Node.js from Upstream | ||
|
|
||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this exclusive with
backport-requested-to? I thought it would be on a PR that hasbackport-requested-to, because the original PR cannot land, but @MylesBorins said it should not - I guess because the PR is landing in the abstract, it just needs to be backported to make that happen. Nees to be more clear.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ping @MylesBorins @nodejs/lts @gib and I are going through nodejs/Release#216 now and hitting this issue. I think
backport-requested-toPRs should have been omitted from the gist/issues in #216 above (or we should adddont-land-onlabels to them, because dont-land-on get omitted).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you can filter based on any tag. Don't land should only apply to prs we do not want to land. If a backport is requested add appropriate tag