From 5c2901391a656a5c3b931590e39a9c182b7aecd3 Mon Sep 17 00:00:00 2001 From: Ruben Bridgewater Date: Sun, 17 Dec 2017 12:59:46 -0300 Subject: doc: update formatting to fit our 80 chars rule This will also use a proper indentation as a couple of entries had a extra indentation of two spaces. PR-URL: https://github.com/nodejs/node/pull/17722 Reviewed-By: Jon Moss Reviewed-By: Luigi Pinca Reviewed-By: James M Snell Reviewed-By: Daniel Bevenius --- doc/onboarding-extras.md | 50 ++++++++++++++++++++++++++++++++---------------- 1 file changed, 34 insertions(+), 16 deletions(-) (limited to 'doc/onboarding-extras.md') diff --git a/doc/onboarding-extras.md b/doc/onboarding-extras.md index 0da3b1b525..a010d8fef1 100644 --- a/doc/onboarding-extras.md +++ b/doc/onboarding-extras.md @@ -42,7 +42,8 @@ | upgrading npm | @fishrock123, @MylesBorins | | upgrading V8 | @nodejs/v8, @nodejs/post-mortem | -When things need extra attention, are controversial, or `semver-major`: @nodejs/tsc +When things need extra attention, are controversial, or `semver-major`: +@nodejs/tsc If you cannot find who to cc for a file, `git shortlog -n -s ` may help. @@ -51,12 +52,14 @@ If you cannot find who to cc for a file, `git shortlog -n -s ` may help. ### By Subsystem -We generally sort issues by a concept of "subsystem" so that we know what part(s) of the codebase it touches. +We generally sort issues by a concept of "subsystem" so that we know what +part(s) of the codebase it touches. **Subsystems generally are**: * `lib/*.js` -* `doc`, `build`, `tools`, `test`, `deps`, `lib / src` (special), and there may be others. +* `doc`, `build`, `tools`, `test`, `deps`, `lib / src` (special), and there may + be others. * `meta` for anything non-code (process) related There may be more than one subsystem valid for any particular issue / PR. @@ -74,13 +77,19 @@ Please use these when possible / appropriate -- * `semver-{minor,major}` - * be conservative – that is, if a change has the remote *chance* of breaking something, go for semver-major + * be conservative – that is, if a change has the remote *chance* of breaking + something, go for semver-major * when adding a semver label, add a comment explaining why you're adding it - * minor vs. patch: roughly: "does it add a new method / does it add a new section to the docs" - * major vs. everything else: run last versions tests against this version, if they pass, **probably** minor or patch - * A breaking change helper ([full source](https://gist.github.com/chrisdickinson/ba532fa0e4e243fb7b44)): + * minor vs. patch: roughly: "does it add a new method / does it add a new + section to the docs" + * major vs. everything else: run last versions tests against this version, if + they pass, **probably** minor or patch + * A breaking change helper + ([full source](https://gist.github.com/chrisdickinson/ba532fa0e4e243fb7b44)): ```sh - git checkout $(git show -s --pretty='%T' $(git show-ref -d $(git describe --abbrev=0) | tail -n1 | awk '{print $1}')) -- test; make -j4 test + SHOW=$(git show-ref -d $(git describe --abbrev=0) | tail -n1 | awk '{print $1}') + git checkout $(git show -s --pretty='%T' $SHOW) -- test + make -j4 test ``` ### LTS/Version labels @@ -92,21 +101,28 @@ We use labels to keep track of which branches a commit should land on: * 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 + * 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 + * 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 + * 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) + * (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 + * 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. @@ -126,6 +142,7 @@ need to be attached anymore, as only important bugfixes will be included. * `git remote add upstream git://github.com/nodejs/node.git` to update from nodejs/node: + * `git checkout master` * `git remote update -p` OR `git fetch --all` (I prefer the former) * `git merge --ff-only upstream/master` (or `REMOTENAME/BRANCH`) @@ -135,5 +152,6 @@ to update from nodejs/node: * commit often, out to your github fork (origin), open a PR * when making PRs make sure to spend time on the description: - * every moment you spend writing a good description quarters the amount of time it takes to understand your code. + * every moment you spend writing a good description quarters the amount of + time it takes to understand your code. * usually prefer to only squash at the *end* of your work, depends on the change -- cgit v1.2.3