Uh oh!
There was an error while loading. Please reload this page.
doc: add triaging for lts releases guide - #20165
Conversation
How does this guide relate to the https://github.com/nodejs/node/blob/master/doc/guides/backporting-to-release-lines.md ? |
richardlau
commented
Apr 20, 2018
Are the mechanics of backporting to LTS different from backporting to current? |
MylesBorins
commented
Apr 20, 2018
@vsemozhetbyt I'll review both documents and see if there is value in merging them or having different docs... might be good to have a separate one specifically about triaging. @richardlau backporting to LTS is the same for external collaborators. Triaging and landing commits (backport and from release lines) is different. |
BethGriggs
commented
Apr 20, 2018
backporting-to-release-lines currently instructs contributors on how to open a backport PR, whereas this guide would document the process of landing the backport PRs/triaging commits to land. Initially I separated it out as I thought it may be confusing to show how to open a backport commit (applicable to any contributor) in the same place as how to land backport PRs/commits on staging branches (collaborator specific). Perhaps any additional content should just be merged and expand the COLLABORATOR_GUIDE.md#technical-howto? The main aim is to make it easier/clearer for any collaborator to traige and pull commits into the staging branches. |
BridgeAR
commented
Apr 25, 2018
@nodejs/documentation PTAL |
@BethGriggs is this still WIP? (Please use the labels for that by the way) |
There was a problem hiding this comment.
Should this be called "Creating a release" instead.
There was a problem hiding this comment.
+1 to preparing an LTS release or Triaging for LTS releases
There was a problem hiding this comment.
Nit: shas -> SHAs or even SHA checksums or whatever the best word (instead of checksums) might be there (commit hashes?).
BridgeAR
commented
May 29, 2018
Closing due to no response. @BethGriggs please feel free to reopen / leave a comment in case you would like to work on this again or open a new PR. |
gibfahn
commented
May 29, 2018
We really need this. |
jasnell
commented
May 29, 2018
+1 to reopening... closing this was premature. |
BethGriggs
commented
May 31, 2018
I have been on vacation - planning to sync up with @MylesBorins this week to progress this guide. |
BethGriggs
commented
Jun 5, 2018
@MylesBorins, what do you think should happen to this guide based on discussions at the Berlin summit about a process change (e.g. about utilizing minor and patch branches from @BridgeAR)? Have we written that proposal down anywhere? |
gibfahn
commented
Jun 5, 2018
Not Myles Borins 😁, but my preference would be to document the process as is, and then we can use the PR to update it with the new proposal to discuss how exactly that should work. |
MylesBorins
left a comment
There was a problem hiding this comment.
So I've added some comments in line.
I'm curious, this guide mostly breaks down to a handful of git-fu. Perhaps it makes sense to make a separate git guide for core that includes aliases and techniques and focus on how to decide if a commit should land and branch-diff techniques for this guide?
Also open to landing all the things in here, but there is the risk of repeated information
There was a problem hiding this comment.
+1 to preparing an LTS release or Triaging for LTS releases
There was a problem hiding this comment.
can you explain --origin DANGER rather than upstream which is usually the convention I've seen used
There was a problem hiding this comment.
That was a suggestion from @gibfahn for my setup - i'll swap it back to upstream so that it is consistent with other docs.
There was a problem hiding this comment.
i usually do git remote update -p
There was a problem hiding this comment.
alternatively you can fix this manually while landing
There was a problem hiding this comment.
I've ended up removing --whitespace=fix as it can cause some serious issues with certain backports.
There was a problem hiding this comment.
sometimes I'll just run the tests for the PR in question when backporting rather than running all the tests
see: https://github.com/MylesBorins/dot-files/blob/master/.bash_profile#L64
There was a problem hiding this comment.
branch-diff vX.x-staging upstream/vY.x -exclude-label semver-major,semver-minor,dont-land-on-vX.x,backport-requested-vX.x,backported-to-vX.x,baking-for-lts --filter-release
where X = LTS branch and Y = Current branch
There was a problem hiding this comment.
$ branch-diff vX.x-staging upstream/master --exclude-label semver-major,dont-land-on-vX.x,backport-requested-vX.x,backported-to-vX.x --filter-release --format=sha --reverse > commits
$ cat commits | xargs git cherry-pick
There was a problem hiding this comment.
this will only work when doing the above step
01e9436 to
7a82142CompareThere was a problem hiding this comment.
I'd say this should come at the top before the Triage PRs section potentially?
There was a problem hiding this comment.
For ease of understanding it might be helpful to add that this patch flow also applies to commits, and add a section to commit triaging that includes an example similar to:$ git pa https://github.com/nodejs/node/commit/1a2b3c4d
c1f78e3 to
3087c7dComparec81ec9e to
4847890Compare4847890 to
f53ed14CompareThere was a problem hiding this comment.
| Go through PRs with the label `vN.x`. e.g. [PRs with the v8.x label](https://github.com/nodejs/node/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc+label%3Av8.x). | |
| Go through PRs with the label `vN.x`. e.g. [PRs with the `v8.x` label](https://github.com/nodejs/node/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc+label%3Av8.x). |
f53ed14 to
cc7f4c7CompareTrott
commented
Dec 4, 2018
Add a section on triaging commits and PRs to land in releases.
Trott
commented
Dec 5, 2018
Trott
commented
Dec 5, 2018
Landed in a845d7a |
Add a section on triaging commits and PRs to land in releases. PR-URL: nodejs#20165 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Add a section on triaging commits and PRs to land in releases. PR-URL: #20165 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Add a section on triaging commits and PRs to land in releases. PR-URL: #20165 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Add a section on triaging commits and PRs to land in releases. PR-URL: #20165 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Add a section on triaging commits and PRs to land in releases. PR-URL: nodejs#20165 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Add a section on triaging commits and PRs to land in releases. PR-URL: #20165 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Add a section on triaging commits and PRs to land in releases. PR-URL: #20165 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Add a section on triaging commits and PRs to land in releases. PR-URL: #20165 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Adds info for backporting commits and PRs to LTS branches.
If we can get a guideline process agreed and written down, it should make it easier for more people to help out with the backporting.
//cc @gibfahn, @MylesBorins
Checklist