Extendable ca certs v4

.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)
 

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
@@ -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** <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) -