1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
|
## Who to CC in issues
* `lib/buffer`: @trevnorris
* `lib/child_process`: @cjihrig, @bnoordhuis, @piscisaereus
* `lib/cluster`: @cjihrig, @bnoordhuis, @piscisaereus
* `lib/{crypto,tls,https}`: @indutny, @shigeki, @nodejs/crypto
* `lib/domains`: @misterdjules
* `lib/{_}http{*}`: @indutny, @bnoordhuis, @nodejs/http
* `lib/net`: @indutny, @bnoordhuis, @piscisaereus, @chrisdickinson, @nodejs/streams
* `lib/{_}stream{s|*}`: @nodejs/streams
* `lib/repl`: @fishrock123
* `lib/timers`: @fishrock123, @misterdjules
* `lib/zlib`: @indutny, @bnoordhuis
* `src/async-wrap.*`: @trevnorris
* `src/node_crypto.*`: @indutny, @shigeki, @nodejs/crypto
* `test/*`: @nodejs/testing, @trott
* `tools/eslint`, `.eslintrc`: @silverwind, @trott
* upgrading v8: @bnoordhuis / @targos / @ofrobots
* upgrading npm: @thealphanerd, @fishrock123
When things need extra attention, are controversial, or `semver-major`: @nodejs/ctc
If you cannot find who to cc for a file, `git shortlog -n -s <file>` may help.
## Labels
### By Subsystem
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.
* `meta` for anything non-code (process) related
There may be more than one subsystem valid for any particular issue / PR.
### General
Please use these when possible / appropriate
* `confirmed-bug` - Bugs you have verified exist
* `discuss` - Things that need larger discussion
* `feature request` - Any issue that requests a new feature (usually not PRs)
* `good first contribution` - Issues suitable for newcomers to process
* `semver-{minor,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)):
```
git checkout $(git show -s --pretty='%T' $(git show-ref -d $(git describe --abbrev=0) | tail -n1 | awk '{print $1}')) -- test; make -j8 test
```
### Other Labels
* Operating system labels
* `os x`, `windows`, `solaris`
* No linux, linux is the implied default
* Architecture labels
* `arm`, `mips`
* 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
* `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`)
## If `git am` fails
* if `git am` fails – use `git am --abort`
* this usually means the PR needs updated
* prefer to make the originating user update the code, since they have it fresh in mind
* first, reattempt with `git am -3` (3-way merge)`
* if `-3` still fails, and you need to get it merged:
* `git fetch origin pull/N/head:pr-N && git checkout pr-N && git rebase master`
## best practices
* 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.
* usually prefer to only squash at the *end* of your work, depends on the change
|
