v9.2.0 proposal

BUILDING.md

@@ -39,15 +39,16 @@ in production.
 
 |  System      | Support type | Version                          | Architectures        | Notes            |
 |--------------|--------------|----------------------------------|----------------------|------------------|
-| GNU/Linux    | Tier 1       | kernel >= 2.6.32, glibc >= 2.12  | x86, x64, arm, arm64 |                  |
+| GNU/Linux    | Tier 1       | kernel >= 2.6.32, glibc >= 2.12  | x64, arm, arm64      |                  |
 | macOS        | Tier 1       | >= 10.10                         | x64                  |                  |
-| Windows      | Tier 1       | >= Windows 7 / 2008 R2           | x86, x64             | vs2015 or vs2017 |
+| Windows      | Tier 1       | >= Windows 7 / 2008 R2           | x86, x64             | vs2017           |
 | SmartOS      | Tier 2       | >= 15 < 16.4                     | x86, x64             | see note1        |
 | FreeBSD      | Tier 2       | >= 10                            | x64                  |                  |
 | GNU/Linux    | Tier 2       | kernel >= 3.13.0, glibc >= 2.19  | ppc64le >=power8     |                  |
 | AIX          | Tier 2       | >= 7.1 TL04                      | ppc64be >=power7     |                  |
 | GNU/Linux    | Tier 2       | kernel >= 3.10, glibc >= 2.17    | s390x                |                  |
 | macOS        | Experimental | >= 10.8 < 10.10                  | x64                  | no test coverage |
+| GNU/Linux    | Experimental | kernel >= 2.6.32, glibc >= 2.12  | x86                  | limited CI       |
 | Linux (musl) | Experimental | musl >= 1.0                      | x64                  |                  |
 
 note1 - The gcc4.8-libs package needs to be installed, because node
@@ -76,7 +77,7 @@ Depending on host platform, the selection of toolchains may vary.
 
 #### Windows
 
-* Visual Studio 2015 or Visual C++ Build Tools 2015 or newer
+* Visual Studio 2017 or the Build Tools thereof
 
 ## Building Node.js on supported platforms
 
@@ -192,14 +193,11 @@ $ [sudo] make install
 Prerequisites:
 
 * [Python 2.6 or 2.7](https://www.python.org/downloads/)
-* One of:
-  * [Visual C++ Build Tools](http://landinghub.visualstudio.com/visual-cpp-build-tools)
-  * [Visual Studio 2015 Update 3](https://www.visualstudio.com/), all editions
-    including the Community edition (remember to select
-    "Common Tools for Visual C++ 2015" feature during installation).
-  * [Visual Studio 2017](https://www.visualstudio.com/downloads/), any edition (including the Build Tools SKU).
-    **Required Components:** "MSbuild", "VC++ 2017 v141 toolset" and at least one of the Windows SDKs.
-    *Note*: For "Windows 10 SDK (10.0.15063.0)" only the "Desktop C++ x86 and x64" flavor is required.
+* The "Desktop development with C++" workload from
+  [Visual Studio 2017](https://www.visualstudio.com/downloads/) or the
+  "Visual C++ build tools" workload from the
+  [Build Tools](https://www.visualstudio.com/downloads/#build-tools-for-visual-studio-2017),
+  with the default optional components.
 * Basic Unix tools required for some tests,
   [Git for Windows](http://git-scm.com/download/win) includes Git Bash
   and tools which can be included in the global `PATH`.

CHANGELOG.md

@@ -29,7 +29,8 @@ release.
 </tr>
 <tr>
     <td valign="top">
-<b><a href="doc/changelogs/CHANGELOG_V9.md#9.1.0">9.1.0</a></b><br/>
+<b><a href="doc/changelogs/CHANGELOG_V9.md#9.2.0">9.2.0</a></b><br/>
+<a href="doc/changelogs/CHANGELOG_V9.md#9.1.0">9.1.0</a><br/>
 <a href="doc/changelogs/CHANGELOG_V9.md#9.0.0">9.0.0</a><br/>
     </td>
     <td valign="top">

COLLABORATOR_GUIDE.md

@@ -371,60 +371,45 @@ The TSC should serve as the final arbiter where required.
     * If more than one author has contributed to the PR, keep the most recent
       author when squashing.
 
-Always modify the original commit message to include additional meta
-information regarding the change process:
-
-- A `PR-URL:` line that references the *full* GitHub URL of the original
-  pull request being merged so it's easy to trace a commit back to the
-  conversation that led up to that change.
-- A `Fixes: X` line, where _X_ either includes the *full* GitHub URL
-  for an issue, and/or the hash and commit message if the commit fixes
-  a bug in a previous commit. Multiple `Fixes:` lines may be added if
-  appropriate.
-- A `Refs:` line referencing a URL for any relevant background.
-- A `Reviewed-By: Name <email>` line for yourself and any
-  other Collaborators who have reviewed the change.
-  - Useful for @mentions / contact list if something goes wrong in the PR.
-  - Protects against the assumption that GitHub will be around forever.
-
 Review the commit message to ensure that it adheres to the guidelines outlined
 in the [contributing](./CONTRIBUTING.md#commit-message-guidelines) guide.
 
+Add all necessary [metadata](#metadata) to commit messages before landing.
+
 See the commit log for examples such as
 [this one](https://github.com/nodejs/node/commit/b636ba8186) if unsure
 exactly how to format your commit messages.
 
 Additionally:
 - Double check PRs to make sure the person's _full name_ and email
   address are correct before merging.
-- Except when updating dependencies, all commits should be self
-  contained (meaning every commit should pass all tests). This makes
-  it much easier when bisecting to find a breaking change.
+- All commits should be self-contained (meaning every commit should pass all
+  tests). This makes it much easier when bisecting to find a breaking change.
 
 ### Technical HOWTO
 
-Clear any `am`/`rebase` that may already be underway.
+Clear any `am`/`rebase` that may already be underway:
 
 ```text
 $ git am --abort
 $ git rebase --abort
 ```
 
-Checkout proper target branch
+Checkout proper target branch:
 
 ```text
 $ git checkout master
 ```
 
 Update the tree (assumes your repo is set up as detailed in
-[CONTRIBUTING.md](CONTRIBUTING.md#step-1-fork))
+[CONTRIBUTING.md](CONTRIBUTING.md#step-1-fork)):
 
 ```text
 $ git fetch upstream
 $ git merge --ff-only upstream/master
 ```
 
-Apply external patches
+Apply external patches:
 
 ```text
 $ curl -L https://github.com/nodejs/node/pull/xxx.patch | git am --whitespace=fix
@@ -442,21 +427,19 @@ against the original PR carefully and build/test on at least one platform
 before landing. If the 3-way merge fails, then it is most likely that a conflicting
 PR has landed since the CI run and you will have to ask the author to rebase.
 
-Check and re-review the changes
+Check and re-review the changes:
 
 ```text
 $ git diff upstream/master
 ```
 
-Check number of commits and commit messages
+Check number of commits and commit messages:
 
 ```text
 $ git log upstream/master...master
 ```
 
-If there are multiple commits that relate to the same feature or
-one with a feature and separate with a test for that feature,
-you'll need to use `squash` or `fixup`:
+Squash commits and add metadata:
 
 ```text
 $ git rebase -i upstream/master
@@ -512,9 +495,28 @@ Save the file and close the editor. You'll be asked to enter a new
 commit message for that commit. This is a good moment to fix incorrect
 commit logs, ensure that they are properly formatted, and add
 `Reviewed-By` lines.
+
 * The commit message text must conform to the
 [commit message guidelines](./CONTRIBUTING.md#commit-message-guidelines).
 
+<a name="metadata"></a>
+* Modify the original commit message to include additional metadata regarding
+  the change process. ([`node-core-utils`][] fetches the metadata for you.)
+
+  * Required: A `PR-URL:` line that references the *full* GitHub URL of the
+    original pull request being merged so it's easy to trace a commit back to
+    the conversation that led up to that change.
+  * Optional: A `Fixes: X` line, where _X_ either includes the *full* GitHub URL
+    for an issue, and/or the hash and commit message if the commit fixes
+    a bug in a previous commit. Multiple `Fixes:` lines may be added if
+    appropriate.
+  * Optional: One or more `Refs:` lines referencing a URL for any relevant
+    background.
+  * Required: A `Reviewed-By: Name <email>` line for yourself and any
+    other Collaborators who have reviewed the change.
+    * Useful for @mentions / contact list if something goes wrong in the PR.
+    * Protects against the assumption that GitHub will be around forever.
+
 Run tests (`make -j4 test` or `vcbuild test`). Even though there was a
 successful continuous integration run, other changes may have landed on master
 since then, so running the tests one last time locally is a good practice.
@@ -678,3 +680,4 @@ LTS working group and the Release team.
 [Stability Index]: doc/api/documentation.md#stability-index
 [Enhancement Proposal]: https://github.com/nodejs/node-eps
 [git-username]: https://help.github.com/articles/setting-your-username-in-git/
+[`node-core-utils`]: https://github.com/nodejs/node-core-utils

CONTRIBUTING.md

@@ -334,6 +334,14 @@ use `Refs:`.
    - `Refs: http://eslint.org/docs/rules/space-in-parens.html`
    - `Refs: https://github.com/nodejs/node/pull/3615`
 
+5. If your commit introduces a breaking change (`semver-major`), it should
+contain an explanation about the reason of the breaking change, which
+situation would trigger the breaking change and what is the exact change.
+
+Breaking changes will be listed in the wiki with the aim to make upgrading
+easier.  Please have a look at [Breaking Changes](https://github.com/nodejs/node/wiki/Breaking-changes-between-v4-LTS-and-v6-LTS)
+for the level of detail that's suitable.
+
 Sample complete commit message:
 
 ```txt
@@ -625,6 +633,7 @@ Focus first on the most significant aspects of the change:
 1. Does this change make sense for Node.js?
 2. Does this change make Node.js better, even if only incrementally?
 3. Are there clear bugs or larger scale issues that need attending to?
+4. Is the commit message readable and correct? If it contains a breaking change is it clear enough?
 
 When changes are necessary, *request* them, do not *demand* them, and do not
 assume that the submitter already knows how to add a test or run a benchmark.

LICENSE

@@ -230,7 +230,7 @@ The externally maintained libraries used by Node.js are:
      #  ---------COPYING.libtabe ---- BEGIN--------------------
      #
      #  /*
-     #   * Copyrighy (c) 1999 TaBE Project.
+     #   * Copyright (c) 1999 TaBE Project.
      #   * Copyright (c) 1999 Pai-Hsiang Hsiao.
      #   * All rights reserved.
      #   *

Makefile

@@ -974,6 +974,7 @@ bench-ci: bench
 lint-md-clean:
 	$(RM) -r tools/remark-cli/node_modules
 	$(RM) -r tools/remark-preset-lint-node/node_modules
+	$(RM) tools/.*mdlintstamp
 
 lint-md-build:
 	@if [ ! -d tools/remark-cli/node_modules ]; then \
@@ -983,10 +984,31 @@ lint-md-build:
 		echo "Markdown linter: installing remark-preset-lint-node into tools/"; \
 		cd tools/remark-preset-lint-node && ../../$(NODE) ../../$(NPM) install; fi
 
-lint-md: lint-md-build
-	@echo "Running Markdown linter..."
-	$(NODE) tools/remark-cli/cli.js -q -f \
-		./*.md doc src lib benchmark tools/doc/ tools/icu/
+ifneq ("","$(wildcard tools/remark-cli/node_modules/)")
+LINT_MD_TARGETS = src lib benchmark tools/doc tools/icu
+LINT_MD_ROOT_DOCS := $(wildcard *.md)
+LINT_MD_FILES := $(shell find $(LINT_MD_TARGETS) -type f \
+  -not -path '*node_modules*' -name '*.md') $(LINT_MD_ROOT_DOCS)
+LINT_DOC_MD_FILES = $(shell ls doc/**/*.md)
+
+tools/.docmdlintstamp: $(LINT_DOC_MD_FILES)
+	@echo "Running Markdown linter on docs..."
+	@$(NODE) tools/remark-cli/cli.js -q -f $(LINT_DOC_MD_FILES)
+	@touch $@
+
+tools/.miscmdlintstamp: $(LINT_MD_FILES)
+	@echo "Running Markdown linter on misc docs..."
+	@$(NODE) tools/remark-cli/cli.js -q -f $(LINT_MD_FILES)
+	@touch $@
+
+tools/.mdlintstamp: tools/.miscmdlintstamp tools/.docmdlintstamp
+
+lint-md: | tools/.mdlintstamp
+else
+lint-md:
+	@echo "The markdown linter is not installed."
+	@echo "To install (requires internet access) run: $ make lint-md-build"
+endif
 
 LINT_JS_TARGETS = benchmark doc lib test tools
 LINT_JS_CMD = tools/eslint/bin/eslint.js --cache \
@@ -1048,10 +1070,13 @@ LINT_CPP_FILES = $(filter-out $(LINT_CPP_EXCLUDE), $(wildcard \
 # and the actual filename is generated so it won't match header guards
 ADDON_DOC_LINT_FLAGS=-whitespace/ending_newline,-build/header_guard
 
-lint-cpp:
+lint-cpp: tools/.cpplintstamp
+
+tools/.cpplintstamp: $(LINT_CPP_FILES)
 	@echo "Running C++ linter..."
-	@$(PYTHON) tools/cpplint.py $(LINT_CPP_FILES)
+	@$(PYTHON) tools/cpplint.py $?
 	@$(PYTHON) tools/check-imports.py
+	@touch $@
 
 lint-addon-docs: test/addons/.docbuildstamp
 	@echo "Running C++ linter on addon docs..."
@@ -1087,6 +1112,10 @@ lint:
 lint-ci: lint
 endif
 
+lint-clean:
+	$(RM) tools/.*lintstamp
+	$(RM) .eslintcache
+
 .PHONY: $(TARBALL)-headers \
   all \
   bench \
@@ -1127,6 +1156,7 @@ endif
   install-bin \
   install-includes \
   lint \
+  lint-clean \
   lint-ci \
   lint-cpp \
   lint-js \

benchmark/_http-benchmarkers.js

@@ -91,11 +91,9 @@ class TestDoubleBenchmarker {
   create(options) {
     const child = child_process.fork(this.executable, {
       silent: true,
-      env: {
-        duration: options.duration,
-        connections: options.connections,
-        path: `http://127.0.0.1:${options.port}${options.path}`
-      }
+      env: Object.assign({}, process.env, {
+        test_url: `http://127.0.0.1:${options.port}${options.path}`
+      })
     });
     return child;
   }

benchmark/_test-double-benchmarker.js

@@ -2,6 +2,6 @@
 
 const http = require('http');
 
-http.get(process.env.path, function() {
+http.get(process.env.test_url, function() {
   console.log(JSON.stringify({ throughput: 1 }));
 });

benchmark/events/ee-emit.js

@@ -2,19 +2,51 @@
 const common = require('../common.js');
 const EventEmitter = require('events').EventEmitter;
 
-const bench = common.createBenchmark(main, { n: [2e6] });
+const bench = common.createBenchmark(main, {
+  n: [2e6],
+  argc: [0, 2, 4, 10],
+  listeners: [1, 5, 10],
+});
 
 function main(conf) {
   const n = conf.n | 0;
+  const argc = conf.argc | 0;
+  const listeners = Math.max(conf.listeners | 0, 1);
 
   const ee = new EventEmitter();
 
-  for (var k = 0; k < 10; k += 1)
+  for (var k = 0; k < listeners; k += 1)
     ee.on('dummy', function() {});
 
-  bench.start();
-  for (var i = 0; i < n; i += 1) {
-    ee.emit('dummy');
+  var i;
+  switch (argc) {
+    case 2:
+      bench.start();
+      for (i = 0; i < n; i += 1) {
+        ee.emit('dummy', true, 5);
+      }
+      bench.end(n);
+      break;
+    case 4:
+      bench.start();
+      for (i = 0; i < n; i += 1) {
+        ee.emit('dummy', true, 5, 10, false);
+      }
+      bench.end(n);
+      break;
+    case 10:
+      bench.start();
+      for (i = 0; i < n; i += 1) {
+        ee.emit('dummy', true, 5, 10, false, 5, 'string', true, false, 11, 20);
+      }
+      bench.end(n);
+      break;
+    default:
+      bench.start();
+      for (i = 0; i < n; i += 1) {
+        ee.emit('dummy');
+      }
+      bench.end(n);
+      break;
   }
-  bench.end(n);
 }