-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doc: describe labelling process for backports #12431
Conversation
The description for 'backported-to-v?.x' seems a little confusing. It currently makes it sound as if it's added simply when the backport PR is made and not necessarily when it has been merged. I would have thought the latter would have been the case for that label, otherwise 'backported' seems misleading. |
doc/onboarding-extras.md
Outdated
* Applied to PRs for which a backport PR has been made | ||
* `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, but can be effective as messaging to non-collaborators |
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 there something missing here? Like 'Does not indicate that any specific action is needed...'.
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.
@vsemozhetbyt Thanks! I added … will be taken,
3a2d227
to
9f7dd55
Compare
@mscdex Right… I’ve changed s/made/merged/ but would still welcome feedback from the releasers group to see if that makes sense. |
doc/onboarding-extras.md
Outdated
* 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` | ||
* Used to indicate that a PR needs a manual backport to a branch in order to land on it |
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.
in order to land it on it
? Although I'd be more explicit without anaphoras and say "in order to land the PR on that branch" or something like that.
We might want to indicate this is typically because the commit doesn't land cleanly on the branch although that's implied.
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.
@benjamingr you’re right. I clarified this a bit based on your suggestion, ptal
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.
LGTM, thanks.
9f7dd55
to
ea37ca8
Compare
I'm fine with this in onboarding-extras.md, but if you wanted to put a link in onboarding.md or even just put it directly into onboarding.md, I'd be 👍 to that. (I suspect onboarding-extras should eventually be merged into onboarding.md anyway. It's a short document and I'm not sure I really understand why it ought to be separate.) |
@addaleax would you mind adding a sentence about labels to the newly created backporting guide? See #11099 (comment), I think it makes sense to do it in this PR. |
48c7784
to
eb858d7
Compare
There’s already the link to the
Yup, added a link to the section that’s added here |
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.
Generally LGTM. Small question around if we should change land-on
to cherry-picked-to
* `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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we consider changing this to cherry-picked-to-v?.x
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm good with whatever.
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.
What Sam said, if that's how it'll be used, it's a more descriptive/specific tag, so +1.
eb858d7
to
a1cbe9f
Compare
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.
LGTM for now, we can bikeshed labels later
|
||
* `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 |
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 has backport-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-to
PRs should have been omitted from the gist/issues in #216 above (or we should add dont-land-on
labels 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
* `land-on-v?.x` | ||
* 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
Based on discussion from the first backporting team meeting. PR-URL: nodejs#12431 Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Myles Borins <[email protected]>
a1cbe9f
to
b440e8e
Compare
Landed in b440e8e. Sorry I didn’t just do that earlier, but yes, like Myles said, if you want to continue bikeshedding about this just make your own PRs. |
Based on discussion from the first backporting team meeting. PR-URL: #12431 Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Myles Borins <[email protected]>
Based on discussion from the first backporting team meeting. PR-URL: #12431 Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Myles Borins <[email protected]>
Based on discussion from the first backporting team meeting. PR-URL: #12431 Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Myles Borins <[email protected]>
Based on discussion from the first backporting team meeting. PR-URL: #12431 Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Myles Borins <[email protected]>
Based on discussion from the first backporting team meeting. PR-URL: #12431 Reviewed-By: Benjamin Gruenbaum <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Myles Borins <[email protected]>
Based on discussion from the first backporting team meeting, feedback on the process is welcome!
/cc @nodejs/release @nodejs/lts