Release proposal: v10.12.0

.editorconfig

@@ -1,40 +1,26 @@
 root = true
 
 [*]
-end_of_line = lf
 charset = utf-8
-trim_trailing_whitespace = true
+end_of_line = lf
+indent_size = 2
+indent_style = space
 insert_final_newline = true
+trim_trailing_whitespace = true
 
 [vcbuild.bat]
 end_of_line = crlf
 
-[{lib,test,tools}/**.js]
-indent_style = space
-indent_size = 2
-
-[src/**.{h,cc}]
-indent_style = space
-indent_size = 2
-
-[test/*.py]
-indent_style = space
-indent_size = 2
-
-[configure]
-indent_style = space
-indent_size = 2
-
 [Makefile]
-indent_style = tab
 indent_size = 8
+indent_style = tab
 
 [{deps}/**]
-indent_style = ignore
-indent_size = ignore
+charset = ignore
 end_of_line = ignore
+indent_size = ignore
+indent_style = ignore
 trim_trailing_whitespace = ignore
-charset = ignore
 
 [{test/fixtures,deps,tools/node_modules,tools/gyp,tools/icu,tools/msvs}/**]
 insert_final_newline = false

.eslintrc.js

@@ -123,27 +123,28 @@ module.exports = {
     'no-proto': 'error',
     'no-redeclare': 'error',
     'no-restricted-modules': ['error', 'sys'],
+    /* eslint-disable max-len */
     'no-restricted-properties': [
       'error',
       {
         object: 'assert',
         property: 'deepEqual',
-        message: 'Use assert.deepStrictEqual().',
+        message: 'Use `assert.deepStrictEqual()`.',
       },
       {
         object: 'assert',
         property: 'notDeepEqual',
-        message: 'Use assert.notDeepStrictEqual().',
+        message: 'Use `assert.notDeepStrictEqual()`.',
       },
       {
         object: 'assert',
         property: 'equal',
-        message: 'Use assert.strictEqual() rather than assert.equal().',
+        message: 'Use `assert.strictEqual()` rather than `assert.equal()`.',
       },
       {
         object: 'assert',
         property: 'notEqual',
-        message: 'Use assert.notStrictEqual() rather than assert.notEqual().',
+        message: 'Use `assert.notStrictEqual()` rather than `assert.notEqual()`.',
       },
       {
         property: '__defineGetter__',
@@ -154,7 +155,6 @@ module.exports = {
         message: '__defineSetter__ is deprecated.',
       }
     ],
-    /* eslint-disable max-len */
     // If this list is modified, please copy the change to lib/.eslintrc.yaml
     // and test/.eslintrc.yaml.
     'no-restricted-syntax': [
@@ -169,31 +169,31 @@ module.exports = {
       },
       {
         selector: "CallExpression[callee.object.name='assert'][callee.property.name='rejects'][arguments.length<2]",
-        message: 'assert.rejects() must be invoked with at least two arguments.',
+        message: '`assert.rejects()` must be invoked with at least two arguments.',
       },
       {
         selector: "CallExpression[callee.object.name='assert'][callee.property.name='strictEqual'][arguments.2.type='Literal']",
         message: 'Do not use a literal for the third argument of assert.strictEqual()'
       },
       {
         selector: "CallExpression[callee.object.name='assert'][callee.property.name='throws'][arguments.1.type='Literal']:not([arguments.1.regex])",
-        message: 'Use an object as second argument of assert.throws()',
+        message: 'Use an object as second argument of `assert.throws()`.',
       },
       {
         selector: "CallExpression[callee.object.name='assert'][callee.property.name='throws'][arguments.length<2]",
-        message: 'assert.throws() must be invoked with at least two arguments.',
+        message: '`assert.throws()` must be invoked with at least two arguments.',
       },
       {
         selector: "CallExpression[callee.name='setTimeout'][arguments.length<2]",
-        message: 'setTimeout() must be invoked with at least two arguments.',
+        message: '`setTimeout()` must be invoked with at least two arguments.',
       },
       {
         selector: "CallExpression[callee.name='setInterval'][arguments.length<2]",
-        message: 'setInterval() must be invoked with at least 2 arguments.',
+        message: '`setInterval()` must be invoked with at least two arguments.',
       },
       {
         selector: 'ThrowStatement > CallExpression[callee.name=/Error$/]',
-        message: 'Use new keyword when throwing an Error.',
+        message: 'Use `new` keyword when throwing an `Error`.',
       }
     ],
     /* eslint-enable max-len */

.gitignore

@@ -15,6 +15,7 @@
 !.mailmap
 !.nycrc
 !.travis.yml
+!.eslintrc.yaml
 
 core
 vgcore.*
@@ -38,14 +39,15 @@ icu_config.gypi
 .eslintcache
 node_trace.*.log
 coverage/
+!**/node_modules/**/coverage
 
 /out
 
 # various stuff that VC++ produces/uses
 Debug/
 !**/node_modules/debug/
-!deps/v8/src/debug/
 Release/
+!**/node_modules/**/release
 !doc/blog/**
 *.sln
 !nodemsi.sln
@@ -64,7 +66,6 @@ ipch/
 *.VC.opendb
 .vs/
 .vscode/
-/deps/v8/src/debug/obj
 /*.exe
 
 /config.mk
@@ -98,6 +99,7 @@ deps/openssl/openssl.xml
 deps/openssl/openssl.target.mk
 deps/zlib/zlib.target.mk
 
+!deps/npm/node_modules
 # not needed and causes issues for distro packagers
 deps/npm/node_modules/.bin/
 
@@ -130,8 +132,4 @@ deps/uv/docs/src/guide/
 # ignore VS compiler output unhandled by V8's .gitignore
 deps/v8/gypfiles/Debug/
 deps/v8/gypfiles/Release/
-deps/v8/src/Debug/
-deps/v8/src/Release/
-deps/v8/src/inspector/Debug/
-deps/v8/src/inspector/Release/
 deps/v8/third_party/eu-strip/

.travis.yml

@@ -8,12 +8,12 @@ matrix:
   include:
     - name: "Linter"
       node_js: "latest"
-      env: 
+      env:
         - NODE=$(which node)
-      install:
-        - make lint-md-build
       script:
         - make lint
+        # Lint the first commit in the PR.
+        - git log $TRAVIS_COMMIT_RANGE --pretty=format:'%h' --no-merges | tail -1 | xargs npx core-validate-commit --no-validate-metadata
     - name: "Test Suite"
       install:
         - ./configure

BUILDING.md

@@ -1,13 +1,50 @@
 # Building Node.js
 
-Depending on what platform or features you require, the build process may
-differ slightly. After you've successfully built a binary, running the
-test suite to validate that the binary works as intended is a good next step.
+Depending on what platform or features you need, the build process may
+differ. After you've built a binary, running the
+test suite to confirm that the binary works as intended is a good next step.
 
-If you can reproduce a test failure consistently, search for it in the
+If you can reproduce a test failure, search for it in the
 [Node.js issue tracker](https://github.com/nodejs/node/issues) or
 file a new issue.
 
+## Table of Contents
+
+* [Supported platforms](#supported-platforms)
+  * [Input](#input)
+  * [Strategy](#strategy)
+  * [Supported platforms](#supported-platforms-1)
+  * [Supported toolchains](#supported-toolchains)
+    * [Unix](#unix)
+    * [AIX](#aix)
+    * [Windows](#windows)
+    * [OpenSSL asm support](#openssl-asm-support)
+* [Building Node.js on supported platforms](#building-nodejs-on-supported-platforms)
+  * [Unix/macOS](#unixmacos)
+    * [Prerequisites](#prerequisites)
+    * [Building Node.js](#building-nodejs-1)
+    * [Running Tests](#running-tests)
+    * [Building the documentation](#building-the-documentation)
+    * [Building a debug build](#building-a-debug-build)
+  * [Windows](#windows-1)
+  * [Android/Android-based devices (e.g. Firefox OS)](#androidandroid-based-devices-eg-firefox-os)
+  * [`Intl` (ECMA-402) support](#intl-ecma-402-support)
+    * [Default: `small-icu` (English only) support](#default-small-icu-english-only-support)
+    * [Build with full ICU support (all locales supported by ICU)](#build-with-full-icu-support-all-locales-supported-by-icu)
+      * [Unix/macOS](#unixmacos-1)
+      * [Windows](#windows-2)
+    * [Building without Intl support](#building-without-intl-support)
+      * [Unix/macOS](#unixmacos-2)
+      * [Windows](#windows-3)
+    * [Use existing installed ICU (Unix/macOS only)](#use-existing-installed-icu-unixmacos-only)
+    * [Build with a specific ICU](#build-with-a-specific-icu)
+      * [Unix/macOS](#unixmacos-3)
+      * [Windows](#windows-4)
+* [Building Node.js with FIPS-compliant OpenSSL](#building-nodejs-with-fips-compliant-openssl)
+* [Building Node.js with external core modules](#building-nodejs-with-external-core-modules)
+  * [Unix/macOS](#unixmacos-4)
+  * [Windows](#windows-5)
+
 ## Supported platforms
 
 This list of supported platforms is current as of the branch/release to

CHANGELOG.md

@@ -31,7 +31,8 @@ release.
 </tr>
 <tr>
     <td valign="top">
-<b><a href="doc/changelogs/CHANGELOG_V10.md#10.11.0">10.11.0</a></b><br/>
+<b><a href="doc/changelogs/CHANGELOG_V10.md#10.12.0">10.12.0</a></b><br/>
+<a href="doc/changelogs/CHANGELOG_V10.md#10.11.0">10.11.0</a><br/>
 <a href="doc/changelogs/CHANGELOG_V10.md#10.10.0">10.10.0</a><br/>
 <a href="doc/changelogs/CHANGELOG_V10.md#10.9.0">10.9.0</a><br/>
 <a href="doc/changelogs/CHANGELOG_V10.md#10.8.0">10.8.0</a><br/>

COLLABORATOR_GUIDE.md

@@ -83,10 +83,11 @@ necessary.
 ### Author ready pull requests
 
 A pull request that is still awaiting the minimum review time is considered
-_author ready_ as soon as the CI has been started, it has at least one approval,
-and it has no outstanding review comments. Please always make sure to add the
-`author ready` label to the PR in that case and remove it again as soon as that
-condition is not met anymore.
+_author ready_ as soon as the CI has been started, it has at least two approvals
+(one Collaborator approval is enough if the pull request has been open for more
+than 7 days), and it has no outstanding review comments. Please always make sure
+to add the `author ready` label to the PR in that case and remove it again as
+soon as that condition is not met anymore.
 
 ### Handling own pull requests
 
@@ -112,10 +113,11 @@ comment that explains why the PR does not require a CI run.
 
 ### Code Reviews
 
-All pull requests must be reviewed and accepted by a Collaborator with
-sufficient expertise who is able to take full responsibility for the
-change. In the case of pull requests proposed by an existing
-Collaborator, an additional Collaborator is required for sign-off.
+At least two Collaborators must approve a pull request before the pull request
+lands. (One Collaborator approval is enough if the pull request has been open
+for more than 7 days.) Approving a pull request indicates that the Collaborator
+accepts responsibility for the change. Approval must be from Collaborators who
+are not authors of the change.
 
 In some cases, it may be necessary to summon a GitHub team to a pull request for
 review by @-mention.
@@ -170,10 +172,10 @@ agenda.
 ### Waiting for Approvals
 
 Before landing pull requests, sufficient time should be left for input
-from other Collaborators. In general, leave at least 48 hours during the
-week and 72 hours over weekends to account for international time
-differences and work schedules. However, certain types of pull requests
-can be fast-tracked and may be landed after a shorter delay. For example:
+from other Collaborators. In general, leave at least 48 hours to account for
+international time differences and work schedules. However, certain types of
+pull requests can be fast-tracked and may be landed after a shorter delay. For
+example:
 
 * Focused changes that affect only documentation and/or the test suite:
   * `code-and-learn` tasks typically fall into this category.
@@ -183,9 +185,12 @@ can be fast-tracked and may be landed after a shorter delay. For example:
   * Regressions that happen right before a release, or reported soon after.
 
 When a pull request is deemed suitable to be fast-tracked, label it with
-`fast-track`. The pull request can be landed once 2 or more Collaborators
-approve both the pull request and the fast-tracking request, and the necessary
-CI testing is done.
+`fast-track` and add a comment that collaborators may upvote. Please mention any
+Collaborators that previously approved the pull request. If someone disagrees
+with the fast-tracking request, remove the label and leave a comment indicating
+why the pull request should not be fast-tracked. The pull request can be landed
+once two or more Collaborators approve both the pull request and the
+fast-tracking request, and the necessary CI testing is done.
 
 ### Testing and CI
 
@@ -408,10 +413,6 @@ Pull requests introducing new core modules:
 New core modules must be landed with a [Stability Index][] of Experimental,
 and must remain Experimental until a semver-major release.
 
-For new modules that involve significant effort, non-trivial additions to
-Node.js or significant new capabilities, an [Enhancement Proposal][] is
-recommended but not required.
-
 ### Additions to N-API
 
 N-API provides an ABI stable API that we will have to support in future
@@ -486,16 +487,20 @@ level.
 
 ### Involving the TSC
 
-Collaborators may opt to elevate pull requests or issues to the [TSC][] for
-discussion by assigning the `tsc-review` label or @-mentioning the
-`@nodejs/tsc` GitHub team. This should be done where a pull request:
+Collaborators may opt to elevate pull requests or issues to the [TSC][].
+This should be done where a pull request:
 
 - is labeled `semver-major`, or
 - has a significant impact on the codebase, or
 - is inherently controversial, or
 - has failed to reach consensus amongst the Collaborators who are
   actively participating in the discussion.
 
+Assign the `tsc-review` label or @-mention the
+`@nodejs/tsc` GitHub team if you want to elevate an issue to the [TSC][].
+Do not use the GitHub UI on the right hand side to assign to
+`@nodejs/tsc` or request a review from `@nodejs/tsc`.
+
 The TSC should serve as the final arbiter where required.
 
 ## Landing Pull Requests
@@ -695,9 +700,12 @@ $ git rev-list upstream/master...HEAD | xargs core-validate-commit
 Optional: When landing your own commits, force push the amended commit to the
 branch you used to open the pull request. If your branch is called `bugfix`,
 then the command would be `git push --force-with-lease origin master:bugfix`.
-When the pull request is closed, this will cause the pull request to
-show the purple merged status rather than the red closed status that is
-usually used for pull requests that weren't merged.
+Don't manually close the PR, GitHub will close it automatically later after you
+push it upstream, and will mark it with the purple merged status rather than the
+red closed status. If you close the PR before GitHub adjusts its status, it will
+show up as a 0 commit PR and the changed file history will be empty. Also if you
+push upstream before you push to your branch, GitHub will close the issue with
+red status so the order of operations is important.
 
 Time to push it:
 
@@ -846,7 +854,7 @@ LTS working group and the Release team.
 | ---                                      | ---                                                                   |
 | `benchmark/*`                            | @nodejs/benchmarking, @mscdex                                         |
 | `doc/*`, `*.md`                          | @nodejs/documentation                                                 |
-| `lib/assert`                             | @nodejs/testing                                                       |
+| `lib/assert`                             | @nodejs/assert                                                        |
 | `lib/async_hooks`                        | @nodejs/async\_hooks for bugs/reviews (+ @nodejs/diagnostics for API) |
 | `lib/buffer`                             | @nodejs/buffer                                                        |
 | `lib/child_process`                      | @nodejs/child\_process                                                |
@@ -889,7 +897,6 @@ When things need extra attention, are controversial, or `semver-major`:
 If you cannot find who to cc for a file, `git shortlog -n -s <file>` may help.
 
 ["Merge Pull Request"]: https://help.github.com/articles/merging-a-pull-request/#merging-a-pull-request-on-github
-[Enhancement Proposal]: https://github.com/nodejs/node-eps
 [Stability Index]: doc/api/documentation.md#stability-index
 [TSC]: https://github.com/nodejs/TSC
 [_Deprecation_]: https://en.wikipedia.org/wiki/Deprecation