1berry/nodejs
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

doc: describe labelling process for backports

Browse Source 
Based on discussion from the first backporting team meeting.

PR-URL: https://github.com/nodejs/node/pull/12431
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
This commit is contained in:
Anna Henningsen 2017-04-15 22:05:00 +02:00
parent f37e3b143a
commit b440e8e4e4
No known key found for this signature in database
GPG Key ID: D8B9F5AEAE84E4CF
1 changed files with 27 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
doc/onboarding-extras.md
View File

@ -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 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`
* 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 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 ### Other Labels
@ -89,10 +116,6 @@ Please use these when possible / appropriate
* Architecture labels * Architecture labels
* `arm`, `mips`, `s390`, `ppc` * `arm`, `mips`, `s390`, `ppc`
* No x86{_64}, since that is the implied default * No x86{_64}, since that is the implied default
* `lts-agenda`, `lts-watch-v*`
* tag things that should be discussed to go into LTS or should go into a specific LTS branch
* (usually only semver-patch things)
* will come more naturally over time
## Updating Node.js from Upstream ## Updating Node.js from Upstream