v7.x-staging update proposal

.eslintignore

@@ -6,3 +6,4 @@ test/disabled
 test/tmp*/
 tools/eslint
 node_modules
+benchmark/tmp/

.eslintrc

@@ -62,17 +62,21 @@ rules:
   no-new-require: 2
   no-path-concat: 2
   no-restricted-modules: [2, sys, _linklist]
-  no-restricted-properties: [2, {
-    object: assert,
-    property: deepEqual,
-    message: Please use assert.deepStrictEqual().
-  }, {
-    property: __defineGetter__,
-    message: __defineGetter__ is deprecated.
-  }, {
-    property: __defineSetter__,
-    message: __defineSetter__ is deprecated.
-  }]
+  no-restricted-properties:
+    - 2
+    - object: assert
+      property: deepEqual
+      message: Use assert.deepStrictEqual().
+    - object: assert
+      property: equal
+      message: Use assert.strictEqual() rather than assert.equal().
+    - object: assert
+      property: notEqual
+      message: Use assert.notStrictEqual() rather than assert.notEqual().
+    - property: __defineGetter__
+      message: __defineGetter__ is deprecated.
+    - property: __defineSetter__,
+      message: __defineSetter__ is deprecated.
 
   # Stylistic Issues
   # http://eslint.org/docs/rules/#stylistic-issues
@@ -84,7 +88,11 @@ rules:
   eol-last: 2
   func-call-spacing: 2
   func-name-matching: 2
-  indent: [2, 2, {SwitchCase: 1, MemberExpression: 1}]
+  indent: [2, 2, {ArrayExpression: first,
+                  CallExpression: {arguments: first},
+                  MemberExpression: 1,
+                  ObjectExpression: first,
+                  SwitchCase: 1}]
   key-spacing: [2, {mode: minimum}]
   keyword-spacing: 2
   linebreak-style: [2, unix]
@@ -120,12 +128,11 @@ rules:
   template-curly-spacing: 2
 
   # Custom rules in tools/eslint-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]
-  no-useless-regex-char-class-escape: [2, { override: ['[', ']'] }]
+  timer-arguments: 2
 
 # Global scoped method and vars
 globals:

BUILDING.md

@@ -109,7 +109,8 @@ Prerequisites:
 * 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.
+    including the Community edition (remember to select
+    "Common Tools for Visual C++ 2015" feature during installation).
 * 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`.
@@ -121,7 +122,7 @@ Prerequisites:
 To run the tests:
 
 ```console
-> .\vcbuild test
+> .\vcbuild nosign test
 ```
 
 To test if Node.js was built correctly:
@@ -179,7 +180,7 @@ $ ./configure --with-intl=full-icu --download=all
 ##### Windows:
 
 ```console
-> .\vcbuild full-icu download-all
+> .\vcbuild nosign full-icu download-all
 ```
 
 #### Building without Intl support
@@ -196,7 +197,7 @@ $ ./configure --without-intl
 ##### Windows:
 
 ```console
-> .\vcbuild without-intl
+> .\vcbuild nosign without-intl
 ```
 
 #### Use existing installed ICU (Unix / OS X only):
@@ -239,7 +240,7 @@ First unpack latest ICU to `deps/icu`
 as `deps/icu` (You'll have: `deps/icu/source/...`)
 
 ```console
-> .\vcbuild full-icu
+> .\vcbuild nosign full-icu
 ```
 
 ## Building Node.js with FIPS-compliant OpenSSL

COLLABORATOR_GUIDE.md

@@ -120,6 +120,7 @@ information regarding the change process:
   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.
@@ -318,9 +319,8 @@ CTC for further discussion.
 
 #### How are LTS Branches Managed?
 
-There are currently three LTS branches: `v4.x`, `v0.10`, and `v0.12`. Each
-of these is paired with a "staging" branch: `v4.x-staging`, `v0.10-staging`,
-and `v0.12-staging`.
+There are currently two LTS branches: `v6.x` and `v4.x`. Each of these is paired
+with a "staging" branch: `v6.x-staging` and `v4.x-staging`.
 
 As commits land in `master`, they are cherry-picked back to each staging
 branch as appropriate. If the commit applies only to the LTS branch, the
@@ -341,18 +341,14 @@ please feel free to include that information in the PR thread.
 
 Several LTS related issue and PR labels have been provided:
 
+* `lts-watch-v6.x` - tells the LTS WG that the issue/PR needs to be considered
+  for landing in the `v6.x-staging` branch.
 * `lts-watch-v4.x` - tells the LTS WG that the issue/PR needs to be considered
   for landing in the `v4.x-staging` branch.
-* `lts-watch-v0.10` - tells the LTS WG that the issue/PR needs to be considered
-  for landing in the `v0.10-staging` branch.
-* `lts-watch-v0.12` - tells the LTS WG that the issue/PR needs to be considered
-  for landing in the `v0.12-staging` branch.
+* `land-on-v6.x` - tells the release team that the commit should be landed
+  in a future v6.x release
 * `land-on-v4.x` - tells the release team that the commit should be landed
   in a future v4.x release
-* `land-on-v0.10` - tells the release team that the commit should be landed
-  in a future v0.10 release
-* `land-on-v0.12` - tells the release team that the commit should be landed
-  in a future v0.12 release
 
 Any collaborator can attach these labels to any PR/issue. As commits are
 landed into the staging branches, the `lts-watch-` label will be removed.

CONTRIBUTING.md

@@ -136,10 +136,13 @@ Check the output of `git log --oneline files_that_you_changed` to find out
 what subsystem (or subsystems) your changes touch.
 
 If your patch fixes an open issue, you can add a reference to it at the end
-of the log. Use the `Fixes:` prefix and the full issue URL. For example:
+of the log. Use the `Fixes:` prefix and the full issue URL. For other references
+use `Refs:`. For example:
 
 ```txt
 Fixes: https://github.com/nodejs/node/issues/1337
+Refs: http://eslint.org/docs/rules/space-in-parens.html
+Refs: https://github.com/nodejs/node/pull/3615
 ```
 
 ### Step 4: Rebase
@@ -167,19 +170,19 @@ $ ./configure && make -j4 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:

README.md

@@ -178,6 +178,8 @@ more information about the governance of the Node.js project, see
 **Julien Gilli** <jgilli@nodejs.org>
 * [mscdex](https://github.com/mscdex) -
 **Brian White** <mscdex@mscdex.net>
+* [MylesBorins](https://github.com/MylesBorins) -
+**Myles Borins** <myles.borins@gmail.com>
 * [ofrobots](https://github.com/ofrobots) -
 **Ali Ijaz Sheikh** <ofrobots@google.com>
 * [rvagg](https://github.com/rvagg) -
@@ -186,8 +188,6 @@ more information about the governance of the Node.js project, see
 **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) -
 **Sakthipriyan Vairamani** <thechargingvolcano@gmail.com>
 * [trevnorris](https://github.com/trevnorris) -
@@ -219,6 +219,8 @@ more information about the governance of the Node.js project, see
 **Claudio Rodriguez** <cjrodr@yahoo.com>
 * [danbev](https://github.com/danbev) -
 **Daniel Bevenius** <daniel.bevenius@gmail.com>
+* [edsadr](https://github.com/edsadr) -
+**Adrian Estrada** <edsadr@gmail.com>
 * [eljefedelrodeodeljefe](https://github.com/eljefedelrodeodeljefe) -
 **Robert Jefe Lindstaedt** <robert.lindstaedt@gmail.com>
 * [estliberitas](https://github.com/estliberitas) -

WORKING_GROUPS.md

@@ -42,7 +42,6 @@ Top Level Working Group](https://github.com/nodejs/TSC/blob/master/WORKING_GROUP
 * [Benchmarking](#benchmarking)
 * [Post-mortem](#post-mortem)
 * [Intl](#intl)
-* [HTTP](#http)
 * [Documentation](#documentation)
 * [Testing](#testing)
 
@@ -189,21 +188,6 @@ Responsibilities include:
 * Publishing regular update summaries and other promotional
   content.
 
-### [HTTP](https://github.com/nodejs/http)
-
-The HTTP Working Group is chartered for the support and improvement of the
-HTTP implementation in Node.js.
-
-Responsibilities include:
-* Addressing HTTP issues on the Node.js issue tracker.
-* Authoring and editing HTTP documentation within the Node.js project.
-* Reviewing changes to HTTP functionality within the Node.js project.
-* Working with the ecosystem of HTTP related module developers to evolve the
-  HTTP implementation and APIs in core.
-* Advising the CTC on all HTTP related issues and discussions.
-* Messaging about the future of HTTP to give the community advance notice of
-  changes.
-
 ### [Docker](https://github.com/nodejs/docker-iojs)
 
 The Docker Working Group's purpose is to build, maintain, and improve official

benchmark/README.md

@@ -161,7 +161,7 @@ For analysing the benchmark results use the `compare.R` tool.
 ```console
 $ cat compare-pr-5134.csv | Rscript benchmark/compare.R
 
-                                                                                      improvement significant      p.value
+                                                                                      improvement confidence      p.value
 string_decoder/string-decoder.js n=250000 chunk=1024 inlen=1024 encoding=ascii           12.46 %         *** 1.165345e-04
 string_decoder/string-decoder.js n=250000 chunk=1024 inlen=1024 encoding=base64-ascii    24.70 %         *** 1.820615e-15
 string_decoder/string-decoder.js n=250000 chunk=1024 inlen=1024 encoding=base64-utf8     23.60 %         *** 2.105625e-12
@@ -171,7 +171,7 @@ string_decoder/string-decoder.js n=250000 chunk=1024 inlen=128  encoding=ascii
 ```
 
 In the output, _improvement_ is the relative improvement of the new version,
-hopefully this is positive. _significant_ tells if there is enough
+hopefully this is positive. _confidence_ tells if there is enough
 statistical evidence to validate the _improvement_. If there is enough evidence
 then there will be at least one star (`*`), more stars is just better. **However
 if there are no stars, then you shouldn't make any conclusions based on the
@@ -189,7 +189,7 @@ may require more runs to obtain (can be set with `--runs`).
 
 _For the statistically minded, the R script performs an [independent/unpaired
 2-group t-test][t-test], with the null hypothesis that the performance is the
-same for both versions. The significant field will show a star if the p-value
+same for both versions. The confidence field will show a star if the p-value
 is less than `0.05`._
 
 The `compare.R` tool can also produce a box plot by using the `--plot filename`
@@ -202,7 +202,7 @@ keep the first line since that contains the header information.
 ```console
 $ cat compare-pr-5134.csv | sed '1p;/encoding=ascii/!d' | Rscript benchmark/compare.R --plot compare-plot.png
 
-                                                                               improvement significant      p.value
+                                                                               improvement confidence      p.value
 string_decoder/string-decoder.js n=250000 chunk=1024 inlen=1024 encoding=ascii    12.46 %         *** 1.165345e-04
 string_decoder/string-decoder.js n=250000 chunk=1024 inlen=128 encoding=ascii      6.70 %           * 2.928003e-02
 string_decoder/string-decoder.js n=250000 chunk=1024 inlen=32 encoding=ascii       7.47 %         *** 5.780583e-04

benchmark/child_process/child-process-read-ipc.js

@@ -1,14 +1,20 @@
 'use strict';
 if (process.argv[2] === 'child') {
   const len = +process.argv[3];
-  const msg = `"${'.'.repeat(len)}"`;
-  while (true) {
-    process.send(msg);
-  }
+  const msg = '.'.repeat(len);
+  const send = () => {
+    while (process.send(msg));
+    // Wait: backlog of unsent messages exceeds threshold
+    setImmediate(send);
+  };
+  send();
 } else {
   const common = require('../common.js');
   const bench = common.createBenchmark(main, {
-    len: [64, 256, 1024, 4096, 32768],
+    len: [
+      64, 256, 1024, 4096, 16384, 65536,
+      65536 << 4, 65536 << 8
+    ],
     dur: [5]
   });
   const spawn = require('child_process').spawn;
@@ -18,7 +24,7 @@ if (process.argv[2] === 'child') {
     const dur = +conf.dur;
     const len = +conf.len;
 
-    const options = { 'stdio': ['ignore', 'ignore', 'ignore', 'ipc'] };
+    const options = { 'stdio': ['ignore', 1, 2, 'ipc'] };
     const child = spawn(process.argv[0],
       [process.argv[1], 'child', len], options);
 
@@ -29,8 +35,7 @@ if (process.argv[2] === 'child') {
 
     setTimeout(function() {
       child.kill();
-      const gbits = (bytes * 8) / (1024 * 1024 * 1024);
-      bench.end(gbits);
+      bench.end(bytes);
     }, dur * 1000);
   }
 }

benchmark/common.js

@@ -195,8 +195,9 @@ function formatResult(data) {
     conf += ' ' + key + '=' + JSON.stringify(data.conf[key]);
   }
 
-  const rate = Math.floor(data.rate)
-                   .toString().replace(/(\d)(?=(\d\d\d)+(?!\d))/g, '$1,');
+  var rate = data.rate.toString().split('.');
+  rate[0] = rate[0].replace(/(\d)(?=(\d\d\d)+(?!\d))/g, '$1,');
+  rate = (rate[1] ? rate.join('.') : rate[0]);
   return `${data.name}${conf}: ${rate}`;
 }
 

benchmark/compare.R

@@ -46,7 +46,7 @@ statistics = ddply(dat, "name", function(subdat) {
   improvement = sprintf("%.2f %%", ((new.mu - old.mu) / old.mu * 100));
 
   p.value = NA;
-  significant = 'NA';
+  confidence = 'NA';
   # Check if there is enough data to calulate the calculate the p-value
   if (length(old.rate) > 1 && length(new.rate) > 1) {
     # Perform a statistics test to see of there actually is a difference in
@@ -56,19 +56,19 @@ statistics = ddply(dat, "name", function(subdat) {
 
     # Add user friendly stars to the table. There should be at least one star
     # before you can say that there is an improvement.
-    significant = '';
+    confidence = '';
     if (p.value < 0.001) {
-      significant = '***';
+      confidence = '***';
     } else if (p.value < 0.01) {
-      significant = '**';
+      confidence = '**';
     } else if (p.value < 0.05) {
-      significant = '*';
+      confidence = '*';
     }
   }
 
   r = list(
     improvement = improvement,
-    significant = significant,
+    confidence = confidence,
     p.value = p.value
   );
   return(data.frame(r));

benchmark/http/create-clientrequest.js

@@ -0,0 +1,23 @@
+'use strict';
+
+var common = require('../common.js');
+var ClientRequest = require('http').ClientRequest;
+
+var bench = common.createBenchmark(main, {
+  pathlen: [1, 8, 16, 32, 64, 128],
+  n: [1e6]
+});
+
+function main(conf) {
+  var pathlen = +conf.pathlen;
+  var n = +conf.n;
+
+  var path = '/'.repeat(pathlen);
+  var opts = { path: path, createConnection: function() {} };
+
+  bench.start();
+  for (var i = 0; i < n; i++) {
+    new ClientRequest(opts);
+  }
+  bench.end(n);
+}