v7.4.0 release proposal

.eslintrc

@@ -76,6 +76,7 @@ rules:
 
   # Stylistic Issues
   # http://eslint.org/docs/rules/#stylistic-issues
+  block-spacing: 2
   brace-style: [2, 1tbs, {allowSingleLine: true}]
   comma-spacing: 2
   comma-style: 2
@@ -93,7 +94,7 @@ rules:
   no-multiple-empty-lines: [2, {max: 2, maxEOF: 0, maxBOF: 0}]
   no-tabs: 2
   no-trailing-spaces: 2
-  operator-linebreak: [2, after, {overrides: {'?': ignore, ':': ignore}}]
+  operator-linebreak: [2, after]
   quotes: [2, single, avoid-escape]
   semi: 2
   semi-spacing: 2

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,5 +1,6 @@
 <!--
-Thank you for your pull request. Please review below requirements.
+Thank you for your pull request. Please provide a description above and review
+the requirements below.
 
 Bug fixes and new features should include tests and possibly benchmarks.
 
@@ -16,7 +17,3 @@ Contributors guide: https://github.com/nodejs/node/blob/master/CONTRIBUTING.md
 
 ##### Affected core subsystem(s)
 <!-- Provide affected core subsystem(s) (like doc, cluster, crypto, etc). -->
-
-
-##### Description of change
-<!-- Provide a description of the change below this comment. -->

BUILDING.md

@@ -24,8 +24,8 @@ On OS X, you will also need:
     this under the menu `Xcode -> Preferences -> Downloads`
   * This step will install `gcc` and the related toolchain containing `make`
 
-* You may want to setup [firewall rules](tools/macosx-firewall.sh) to avoid
-popups asking to accept incoming network connections when running tests:
+* After building, you may want to setup [firewall rules](tools/macosx-firewall.sh)
+to avoid popups asking to accept incoming network connections when running tests:
 
 ```console
 $ sudo ./tools/macosx-firewall.sh

CHANGELOG.md

@@ -28,7 +28,8 @@ release.
 </tr>
 <tr>
   <td valign="top">
-    <b><a href="doc/changelogs/CHANGELOG_V7.md#7.3.0">7.3.0</a></b><br/>
+    <b><a href="doc/changelogs/CHANGELOG_V7.md#7.4.0">7.4.0</a></b><br/>
+    <a href="doc/changelogs/CHANGELOG_V7.md#7.3.0">7.3.0</a><br/>
     <a href="doc/changelogs/CHANGELOG_V7.md#7.2.1">7.2.1</a><br/>
     <a href="doc/changelogs/CHANGELOG_V7.md#7.2.0">7.2.0</a><br/>
     <a href="doc/changelogs/CHANGELOG_V7.md#7.1.0">7.1.0</a><br/>

COLLABORATOR_GUIDE.md

@@ -36,7 +36,7 @@ Collaborators or additional evidence that the issue has relevance, the
 issue may be closed. Remember that issues can always be re-opened if
 necessary.
 
-[**See "Who to CC in issues"**](./onboarding-extras.md#who-to-cc-in-issues)
+[**See "Who to CC in issues"**](./doc/onboarding-extras.md#who-to-cc-in-issues)
 
 ## Accepting Modifications
 

CONTRIBUTING.md

@@ -60,16 +60,21 @@ always welcome but API or behavioral changes to modules at stability level 3
 Node.js has several bundled dependencies in the *deps/* and the *tools/*
 directories that are not part of the project proper. Any changes to files
 in those directories or its subdirectories should be sent to their respective
-projects. Do not send your patch to us, we cannot accept it.
+projects. Do not send a patch to Node.js. We cannot accept such patches.
 
 In case of doubt, open an issue in the
 [issue tracker](https://github.com/nodejs/node/issues/) or contact one of the
 [project Collaborators](https://github.com/nodejs/node/#current-project-team-members).
 Especially do so if you plan to work on something big. Nothing is more
 frustrating than seeing your hard work go to waste because your vision
-does not align with the project team. Node.js has two IRC channels,
-[#Node.js](http://webchat.freenode.net/?channels=node.js) for general help and questions, and
-[#Node-dev](http://webchat.freenode.net/?channels=node-dev) for development of node core specifically.
+does not align with the project team. (Node.js has two IRC channels:
+[#Node.js](http://webchat.freenode.net/?channels=node.js) for general help and
+questions, and
+[#Node-dev](http://webchat.freenode.net/?channels=node-dev) for development of
+Node.js core specifically.
+
+For instructions on updating the version of V8 included in the *deps/*
+directory, please refer to [the Maintaining V8 in Node.js guide](https://github.com/nodejs/node/blob/master/doc/guides/maintaining-V8.md).
 
 
 ### Step 2: Branch
@@ -243,18 +248,85 @@ If in doubt, you can always ask for guidance in the Pull Request or on
 [IRC in the #node-dev channel](https://webchat.freenode.net?channels=node-dev&uio=d4).
 
 Feel free to post a comment in the Pull Request to ping reviewers if you are
-awaiting an answer on something.
+awaiting an answer on something. If you encounter words or acronyms that
+seem unfamiliar, check out this
+[glossary](https://sites.google.com/a/chromium.org/dev/glossary).
 
+Note that multiple commits often get squashed when they are landed (see the
+notes about [commit squashing](#commit-squashing)).
 
 ### Step 8: Landing
 
-Once your Pull Request has been reviewed and approved by at least one Node.js
-Collaborators (often by saying LGTM, or Looks Good To Me), and as long as
-there is consensus (no objections from a Collaborator), a
-Collaborator can merge the Pull Request . GitHub often shows the Pull Request as
- `Closed` at this point, but don't worry. If you look at the branch you raised
- your Pull Request against (probably `master`), you should see a commit with
- your name on it. Congratulations and thanks for your contribution!
+In order to get landed, a Pull Request needs to be reviewed and
+[approved](#getting-approvals-for-your-pull-request) by
+at least one Node.js Collaborator and pass a
+[CI (Continuous Integration) test run](#ci-testing).
+After that, as long as there are no objections
+from a Collaborator, the Pull Request can be merged. If you find your
+Pull Request waiting longer than you expect, see the
+[notes about the waiting time](#waiting-until-the-pull-request-gets-landed).
+
+When a collaborator lands your Pull Request, they will post
+a comment to the Pull Request page mentioning the commit(s) it
+landed as. GitHub often shows the Pull Request as `Closed` at this
+point, but don't worry. If you look at the branch you raised your
+Pull Request against (probably `master`), you should see a commit with
+your name on it. Congratulations and thanks for your contribution!
+
+## Additional Notes
+
+### Commit Squashing
+
+When the commits in your Pull Request get landed, they will be squashed
+into one commit per logical change, with metadata added to the commit
+message (including links to the Pull Request, links to relevant issues,
+and the names of the reviewers). The commit history of your Pull Request,
+however, will stay intact on the Pull Request page.
+
+For the size of "one logical change",
+[0b5191f](https://github.com/nodejs/node/commit/0b5191f15d0f311c804d542b67e2e922d98834f8)
+can be a good example. It touches the implementation, the documentation,
+and the tests, but is still one logical change. In general, the tests should
+always pass when each individual commit lands on the master branch.
+
+### Getting Approvals for Your Pull Request
+
+A Pull Request is approved either by saying LGTM, which stands for
+"Looks Good To Me", or by using GitHub's Approve button.
+GitHub's Pull Request review feature can be used during the process.
+For more information, check out
+[the video tutorial](https://www.youtube.com/watch?v=HW0RPaJqm4g)
+or [the official documentation](https://help.github.com/articles/reviewing-changes-in-pull-requests/).
+
+After you push new changes to your branch, you need to get
+approval for these new changes again, even if GitHub shows "Approved"
+because the reviewers have hit the buttons before.
+
+### CI Testing
+
+Every Pull Request needs to be tested
+to make sure that it works on the platforms that Node.js
+supports. This is done by running the code through the CI system.
+
+Only a Collaborator can request a CI run. Usually one of them will do it
+for you as approvals for the Pull Request come in.
+If not, you can ask a Collaborator to request a CI run.
+
+### Waiting Until the Pull Request Gets Landed
+
+A Pull Request needs to stay open for at least 48 hours (72 hours on a
+weekend) from when it is submitted, even after it gets approved and
+passes the CI. This is to make sure that everyone has a chance to
+weigh in. If the changes are trivial, collaborators may decide it
+doesn't need to wait. A Pull Request may well take longer to be
+merged in. All these precautions are important because Node.js is
+widely used, so don't be discouraged!
+
+### Check Out the Collaborator's Guide
+
+If you want to know more about the code review and the landing process,
+you can take a look at the
+[collaborator's guide](https://github.com/nodejs/node/blob/master/COLLABORATOR_GUIDE.md).
 
 <a id="developers-certificate-of-origin"></a>
 ## Developer's Certificate of Origin 1.1

README.md

@@ -184,6 +184,8 @@ more information about the governance of the Node.js project, see
 **Rod Vagg** <rod@vagg.org>
 * [shigeki](https://github.com/shigeki) -
 **Shigeki Ohtsu** <ohtsu@iij.ad.jp>
+* [targos](https://github.com/targos) -
+**Michaël Zasso** <targos@protonmail.com>
 * [TheAlphaNerd](https://github.com/TheAlphaNerd) -
 **Myles Borins** <myles.borins@gmail.com>
 * [thefourtheye](https://github.com/thefourtheye) -
@@ -251,6 +253,8 @@ more information about the governance of the Node.js project, see
 **João Reis** <reis@janeasystems.com>
 * [joshgav](https://github.com/joshgav) -
 **Josh Gavant** <josh.gavant@outlook.com>
+* [joyeecheung](https://github.com/joyeecheung) -
+**Joyee Cheung** <joyeec9h3@gmail.com>
 * [julianduque](https://github.com/julianduque) -
 **Julian Duque** <julianduquej@gmail.com>
 * [JungMinu](https://github.com/JungMinu) -
@@ -317,8 +321,6 @@ more information about the governance of the Node.js project, see
 **Steven R Loomis** <srloomis@us.ibm.com>
 * [stefanmb](https://github.com/stefanmb) -
 **Stefan Budeanu** <stefan@budeanu.com>
-* [targos](https://github.com/targos) -
-**Michaël Zasso** <targos@protonmail.com>
 * [tellnes](https://github.com/tellnes) -
 **Christian Tellnes** <christian@tellnes.no>
 * [thekemkid](https://github.com/thekemkid) -