Skip to content
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

Merged
merged 1 commit into from
Jul 23, 2017

Conversation

addaleax
Copy link
Member

Based on discussion from the first backporting team meeting, feedback on the process is welcome!

/cc @nodejs/release @nodejs/lts

@nodejs-github-bot nodejs-github-bot added the doc Issues and PRs related to the documentations. label Apr 15, 2017
@mscdex
Copy link
Contributor

mscdex commented Apr 15, 2017

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.

@mscdex mscdex added the meta Issues and PRs related to the general management of the project. label Apr 15, 2017
* 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
Copy link
Contributor

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...'.

Copy link
Member Author

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,

@addaleax addaleax force-pushed the backport-labels branch 2 times, most recently from 3a2d227 to 9f7dd55 Compare April 15, 2017 20:21
@addaleax
Copy link
Member Author

@mscdex Right… I’ve changed s/made/merged/ but would still welcome feedback from the releasers group to see if that makes sense.

* 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
Copy link
Member

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.

Copy link
Member Author

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks.

@Trott
Copy link
Member

Trott commented Apr 16, 2017

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.)

@gibfahn gibfahn mentioned this pull request Apr 16, 2017
2 tasks
@gibfahn
Copy link
Member

gibfahn commented Apr 16, 2017

@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.

@addaleax addaleax force-pushed the backport-labels branch 3 times, most recently from 48c7784 to eb858d7 Compare April 16, 2017 13:58
@addaleax
Copy link
Member Author

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.

There’s already the link to the Labels section in there, so maybe another link to a subsection of it would be a bit confusing?

would you mind adding a sentence about labels to the newly created backporting guide?

Yup, added a link to the section that’s added here

Copy link
Contributor

@MylesBorins MylesBorins left a 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`
Copy link
Contributor

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

Copy link
Contributor

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

Copy link
Member

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.

Copy link
Member

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.

@addaleax addaleax mentioned this pull request Apr 21, 2017
Copy link
Contributor

@MylesBorins MylesBorins left a 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
Copy link
Contributor

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.

Copy link
Contributor

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).

Copy link
Contributor

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`
Copy link
Contributor

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?

Copy link
Contributor

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]>
@addaleax addaleax merged commit b440e8e into nodejs:master Jul 23, 2017
@addaleax
Copy link
Member Author

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.

@addaleax addaleax deleted the backport-labels branch July 23, 2017 14:07
addaleax added a commit that referenced this pull request Jul 24, 2017
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]>
@addaleax addaleax mentioned this pull request Jul 24, 2017
@addaleax addaleax mentioned this pull request Aug 2, 2017
MylesBorins pushed a commit that referenced this pull request Aug 16, 2017
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]>
@MylesBorins MylesBorins mentioned this pull request Aug 16, 2017
MylesBorins pushed a commit that referenced this pull request Aug 16, 2017
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]>
MylesBorins pushed a commit that referenced this pull request Sep 3, 2017
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]>
MylesBorins pushed a commit that referenced this pull request Sep 5, 2017
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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
doc Issues and PRs related to the documentations. meta Issues and PRs related to the general management of the project.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants