Merge tag 'v4.8.0' into v4.x-port

2017-02-21 v4.8.0 'Argon' (LTS) Release
Git-EVTag-v0-SHA512: 39b773101eec1c2d448612c661868cb3751eaf6fadf2a0dd244c38a4c70044ec95f9aa65d60371691ff2d93dfe6c90f3c77921864963314584c629ac09a5e03a

.eslintrc

@@ -65,6 +65,7 @@ rules:
   no-mixed-spaces-and-tabs: 2
   no-multiple-empty-lines: [2, {max: 2}]
   no-trailing-spaces: 2
+  operator-linebreak: [2, after, {overrides: {'?': ignore, ':': ignore}}]
   quotes: [2, "single", "avoid-escape"]
   semi: 2
   space-before-blocks: [2, "always"]
@@ -90,6 +91,7 @@ rules:
   align-function-arguments: 2
   align-multiline-assignment: 2
   assert-fail-single-argument: 2
+  assert-throws-arguments: [2, { requireTwo: false }]
   new-with-error: [2, "Error", "RangeError", "TypeError", "SyntaxError", "ReferenceError"]
 
 # Global scoped method and vars

BUILDING.md

@@ -24,6 +24,15 @@ 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`
 
+* 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
+```
+Running this script will add rules for the executable `node` in the out
+directory and the symbolic `node` link in the projects root directory.
+
 On FreeBSD and OpenBSD, you may also need:
 * libexecinfo (FreeBSD and OpenBSD only)
 
@@ -108,13 +117,13 @@ Prerequisites:
   and tools which can be included in the global `PATH`.
 
 ```text
-> vcbuild nosign
+> .\vcbuild nosign
 ```
 
 To run the tests:
 
 ```text
-> vcbuild test
+> .\vcbuild nosign test
 ```
 
 To test if Node.js was built correctly:
@@ -163,7 +172,7 @@ $ ./configure --with-intl=small-icu --download=all
 ##### Windows:
 
 ```text
-> vcbuild small-icu download-all
+> .\vcbuild nosign small-icu download-all
 ```
 
 The `small-icu` mode builds with English-only data. You can add full
@@ -186,7 +195,7 @@ $ ./configure --with-intl=full-icu --download=all
 ##### Windows:
 
 ```text
-> vcbuild full-icu download-all
+> .\vcbuild nosign full-icu download-all
 ```
 
 #### Building without Intl support
@@ -203,7 +212,7 @@ $ ./configure --with-intl=none
 ##### Windows:
 
 ```text
-> vcbuild intl-none
+> .\vcbuild nosign intl-none
 ```
 
 #### Use existing installed ICU (Unix / OS X only):
@@ -242,7 +251,7 @@ First unpack latest ICU to `deps/icu`
 as `deps/icu` (You'll have: `deps/icu/source/...`)
 
 ```text
-> vcbuild full-icu
+> .\vcbuild nosign full-icu
 ```
 
 ## Building Node.js with FIPS-compliant OpenSSL

CONTRIBUTING.md

@@ -60,17 +60,22 @@ 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
@@ -159,19 +164,19 @@ $ ./configure && make -j8 test
 Windows:
 
 ```text
-> vcbuild test
+ .\vcbuild nosign test
 ```
 
 (See the [BUILDING.md](./BUILDING.md) for more details.)
 
 Make sure the linter is happy and that all tests pass. Please, do not submit
 patches that fail either check.
 
-Running `make test`/`vcbuild test` will run the linter as well unless one or
+Running `make test`/`.\vcbuild nosign test` will run the linter as well unless one or
 more tests fail.
 
 If you want to run the linter without running tests, use
-`make lint`/`vcbuild jslint`.
+`make lint`/`.\vcbuild nosign jslint`.
 
 If you are updating tests and just want to run a single test to check it, you
 can use this syntax to run it exactly as the test harness would:
@@ -240,18 +245,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** <[email protected]>
 * [shigeki](https://github.com/shigeki) -
 **Shigeki Ohtsu** <[email protected]>
+* [targos](https://github.com/targos) -
+**Michaël Zasso** <[email protected]>
 * [TheAlphaNerd](https://github.com/TheAlphaNerd) -
 **Myles Borins** <[email protected]>
 * [thefourtheye](https://github.com/thefourtheye) -
@@ -251,6 +253,8 @@ more information about the governance of the Node.js project, see
 **João Reis** <[email protected]>
 * [joshgav](https://github.com/joshgav) -
 **Josh Gavant** <[email protected]>
+* [joyeecheung](https://github.com/joyeecheung) -
+**Joyee Cheung** <[email protected]>
 * [julianduque](https://github.com/julianduque) -
 **Julian Duque** <[email protected]>
 * [JungMinu](https://github.com/JungMinu) -
@@ -317,8 +321,6 @@ more information about the governance of the Node.js project, see
 **Steven R Loomis** <[email protected]>
 * [stefanmb](https://github.com/stefanmb) -
 **Stefan Budeanu** <[email protected]>
-* [targos](https://github.com/targos) -
-**Michaël Zasso** <[email protected]>
 * [tellnes](https://github.com/tellnes) -
 **Christian Tellnes** <[email protected]>
 * [thekemkid](https://github.com/thekemkid) -