v4.7.0 proposal

.gitignore

@@ -85,7 +85,7 @@ deps/npm/node_modules/.bin/
 # test artifacts
 tools/faketime
 icu_config.gypi
-test.tap
+*.tap
 
 # Xcode workspaces and project folders
 *.xcodeproj

COLLABORATOR_GUIDE.md

@@ -84,7 +84,7 @@ continuous integration tests on the
 ### Involving the CTC
 
 Collaborators may opt to elevate pull requests or issues to the CTC for
-discussion by assigning the ***ctc-agenda*** tag. This should be done
+discussion by assigning the `ctc-review` label. This should be done
 where a pull request:
 
 - has a significant impact on the codebase,
@@ -101,6 +101,8 @@ information regarding the change process:
 
 - 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.
 - 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.

CONTRIBUTING.md

@@ -90,6 +90,13 @@ $ git config --global user.name "J. Random User"
 $ git config --global user.email "j.random.user@example.com"
 ```
 
+Add and commit:
+
+```text
+$ git add my/changed/files
+$ git commit
+```
+
 Writing good commit logs is important. A commit log should describe what
 changed and why. Follow these guidelines when writing one:
 
@@ -191,10 +198,60 @@ $ git push origin my-branch
 Go to https://github.com/yourusername/node and select your branch.
 Click the 'Pull Request' button and fill out the form.
 
-Pull requests are usually reviewed within a few days. If there are comments
-to address, apply your changes in a separate commit and push that to your
-branch. Post a comment in the pull request afterwards; GitHub does
-not send out notifications when you add commits.
+Pull requests are usually reviewed within a few days.
+
+### Step 7: Discuss and update
+
+You will probably get feedback or requests for changes to your Pull Request.
+This is a big part of the submission process, so don't be disheartened!
+
+To make changes to an existing Pull Request, make the changes to your branch.
+When you push that branch to your fork, GitHub will automatically update the
+Pull Request.
+
+You can push more commits to your branch:
+
+```text
+$ git add my/changed/files
+$ git commit
+$ git push origin my-branch
+```
+
+Or you can rebase against master:
+
+```text
+$ git fetch --all
+$ git rebase origin/master
+$ git push --force-with-lease origin my-branch
+```
+
+Or you can amend the last commit (for example if you want to change the commit
+log).
+
+```text
+$ git add any/changed/files
+$ git commit --amend
+$ git push --force-with-lease origin my-branch
+```
+
+**Important:** The `git push --force-with-lease` command is one of the few ways
+to delete history in git. Before you use it, make sure you understand the risks.
+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.
+
+
+### 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!
 
 <a id="developers-certificate-of-origin"></a>
 ## Developer's Certificate of Origin 1.1

GOVERNANCE.md

@@ -23,14 +23,11 @@ The [nodejs/node](https://github.com/nodejs/node) GitHub repository is
 maintained by the CTC and additional Collaborators who are added by the
 CTC on an ongoing basis.
 
-Individuals making significant and valuable contributions are made
-Collaborators and given commit-access to the project. These
-individuals are identified by the CTC and their addition as
-Collaborators is discussed during the weekly CTC meeting.
+Individuals identified by the CTC as making significant and valuable
+contributions are made Collaborators and given commit access to the project.
 
 _Note:_ If you make a significant contribution and are not considered
-for commit-access, log an issue or contact a CTC member directly and it
-will be brought up in the next CTC meeting.
+for commit access, log an issue or contact a CTC member directly.
 
 Modifications of the contents of the nodejs/node repository are made on
 a collaborative basis. Anybody with a GitHub account may propose a
@@ -39,16 +36,21 @@ Collaborators. 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. Consensus should be sought if additional Collaborators
-participate and there is disagreement around a particular
-modification. See [Consensus Seeking Process](#consensus-seeking-process) below
-for further detail on the consensus model used for governance.
+for sign-off.
 
-Collaborators may opt to elevate significant or controversial
-modifications, or modifications that have not found consensus to the
-CTC for discussion by assigning the ***ctc-agenda*** tag to a pull
-request or issue. The CTC should serve as the final arbiter where
-required.
+If one or more Collaborators oppose a proposed change, then the change can not
+be accepted unless:
+
+* Discussions and/or additional changes result in no Collaborators objecting to
+  the change. Previously-objecting Collaborators do not necessarily have to
+  sign-off on the change, but they should not be opposed to it.
+* The change is escalated to the CTC and the CTC votes to approve the change.
+  This should be used only after other options (especially discussion among
+  the disagreeing Collaborators) have been exhausted.
+
+Collaborators may opt to elevate significant or controversial modifications to
+the CTC by assigning the `ctc-review` label to a pull request or issue. The
+CTC should serve as the final arbiter where required.
 
 For the current list of Collaborators, see the project
 [README.md](./README.md#current-project-team-members).
@@ -103,7 +105,7 @@ members affiliated with the over-represented employer(s).
 Typical activities of a CTC member include:
 
 * attending the weekly meeting
-* commenting on the weekly CTC meeting issue and issues labeled `ctc-agenda`
+* commenting on the weekly CTC meeting issue and issues labeled `ctc-review`
 * participating in CTC email threads
 * volunteering for tasks that arise from CTC meetings and related discussions
 * other activities (beyond those typical of Collaborators) that facilitate the
@@ -115,7 +117,8 @@ Collaborator activities as well.
 ### CTC Meetings
 
 The CTC meets weekly in a voice conference call. The meeting is run by a
-designated moderator approved by the CTC. Each meeting is streamed on YouTube.
+designated meeting chair approved by the CTC. Each meeting is streamed on
+YouTube.
 
 Items are added to the CTC agenda which are considered contentious or
 are modifications of governance, contribution policy, CTC membership,
@@ -125,30 +128,46 @@ The intention of the agenda is not to approve or review all patches.
 That should happen continuously on GitHub and be handled by the larger
 group of Collaborators.
 
-Any community member or contributor can ask that something be added to
-the next meeting's agenda by logging a GitHub issue. Any Collaborator,
-CTC member or the moderator can add the item to the agenda by adding
-the ***ctc-agenda*** tag to the issue.
+Any community member or contributor can ask that something be reviewed
+by the CTC by logging a GitHub issue. Any Collaborator, CTC member, or the
+meeting chair can bring the issue to the CTC's attention by applying the
+`ctc-review` label. If consensus-seeking among CTC members fails for a
+particular issue, it may be added to the CTC meeting agenda by adding the
+`ctc-agenda` label.
 
-Prior to each CTC meeting, the moderator will share the agenda with
+Prior to each CTC meeting, the meeting chair will share the agenda with
 members of the CTC. CTC members can also add items to the agenda at the
-beginning of each meeting. The moderator and the CTC cannot veto or remove
+beginning of each meeting. The meeting chair and the CTC cannot veto or remove
 items.
 
 The CTC may invite persons or representatives from certain projects to
 participate in a non-voting capacity.
 
-The moderator is responsible for summarizing the discussion of each agenda item
-and sending it as a pull request after the meeting.
+The meeting chair is responsible for ensuring that minutes are taken and that a
+pull request with the minutes is submitted after the meeting.
+
+Due to the challenges of scheduling a global meeting with participants in
+several timezones, the CTC will seek to resolve as many agenda items as possible
+outside of meetings using
+[the CTC issue tracker](https://github.com/nodejs/CTC/issues). The process in
+the issue tracker is:
+
+* A CTC member opens an issue explaining the proposal/issue and @-mentions
+  @nodejs/ctc.
+* After 72 hours, if there are two or more `LGTM`s from other CTC members and no
+  explicit opposition from other CTC members, then the proposal is approved.
+* If there are any CTC members objecting, then a conversation ensues until
+  either the proposal is dropped or the objecting members are persuaded. If
+  there is an extended impasse, a motion for a vote may be made.
 
 ## Consensus Seeking Process
 
 The CTC follows a
 [Consensus Seeking](http://en.wikipedia.org/wiki/Consensus-seeking_decision-making)
 decision making model.
 
-When an agenda item has appeared to reach a consensus, the moderator will ask
-"Does anyone object?" as a final call for dissent from the consensus.
+When an agenda item has appeared to reach a consensus, the meeting chair will
+ask "Does anyone object?" as a final call for dissent from the consensus.
 
 If an agenda item cannot reach a consensus, a CTC member can call for either a
 closing vote or a vote to table the issue to the next meeting. All votes

Makefile

@@ -71,11 +71,7 @@ out/Makefile: common.gypi deps/uv/uv.gyp deps/http_parser/http_parser.gyp deps/z
 	$(PYTHON) tools/gyp_node.py -f make
 
 config.gypi: configure
-	if [ -f $@ ]; then
-		$(error Stale $@, please re-run ./configure)
-	else
-		$(error No $@, please run ./configure first)
-	fi
+	$(error Missing or stale $@, please run ./$<)
 
 install: all
 	$(PYTHON) tools/install.py $@ '$(DESTDIR)' '$(PREFIX)'
@@ -109,7 +105,7 @@ cctest: all
 	@out/$(BUILDTYPE)/$@
 
 v8:
-	tools/make-v8.sh v8
+	tools/make-v8.sh
 	$(MAKE) -C deps/v8 $(V8_ARCH).$(BUILDTYPE_LOWER) $(V8_BUILD_OPTIONS)
 
 test: | cctest  # Depends on 'all'.
@@ -196,6 +192,7 @@ test-ci-js:
 		$(TEST_CI_ARGS) $(CI_JS_SUITES)
 
 test-ci: | build-addons
+	out/Release/cctest --gtest_output=tap:cctest.tap
 	$(PYTHON) tools/test.py -p tap --logfile test.tap --mode=release --flaky-tests=$(FLAKY_TESTS) \
 		$(TEST_CI_ARGS) $(CI_NATIVE_SUITES) $(CI_JS_SUITES)
 
@@ -287,7 +284,7 @@ out/doc/%: doc/%
 # check if ./node is actually set, else use user pre-installed binary
 gen-json = tools/doc/generate.js --format=json $< > $@
 out/doc/api/%.json: doc/api/%.md
-	[ -e tools/doc/node_modules/js-yaml/package.json ] || \
+	@[ -e tools/doc/node_modules/js-yaml/package.json ] || \
 		[ -e tools/eslint/node_modules/js-yaml/package.json ] || \
 		if [ -x $(NODE) ]; then \
 			cd tools/doc && ../../$(NODE) ../../$(NPM) install; \
@@ -299,7 +296,7 @@ out/doc/api/%.json: doc/api/%.md
 # check if ./node is actually set, else use user pre-installed binary
 gen-html = tools/doc/generate.js --node-version=$(FULLVERSION) --format=html --template=doc/template.html $< > $@
 out/doc/api/%.html: doc/api/%.md
-	[ -e tools/doc/node_modules/js-yaml/package.json ] || \
+	@[ -e tools/doc/node_modules/js-yaml/package.json ] || \
 		[ -e tools/eslint/node_modules/js-yaml/package.json ] || \
 		if [ -x $(NODE) ]; then \
 			cd tools/doc && ../../$(NODE) ../../$(NPM) install; \

README.md

@@ -186,6 +186,8 @@ more information about the governance of the Node.js project, see
 **Shigeki Ohtsu** <ohtsu@iij.ad.jp>
 * [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) -
 **Trevor Norris** <trev.norris@gmail.com>
 * [Trott](https://github.com/Trott) -
@@ -237,10 +239,12 @@ more information about the governance of the Node.js project, see
 **Ilkka Myller** <ilkka.myller@nodefield.com>
 * [isaacs](https://github.com/isaacs) -
 **Isaac Z. Schlueter** <i@izs.me>
+* [italoacasas](https://github.com/italoacasas)
+**Italo A. Casas**  <me@italoacasas.com>
 * [iWuzHere](https://github.com/iWuzHere) -
 **Imran Iqbal** <imran@imraniqbal.org>
 * [JacksonTian](https://github.com/JacksonTian) -
-**Jackson Tian** <shvyo1987@gmail.com>
+**Jackson Tian** <shyvo1987@gmail.com>
 * [jbergstroem](https://github.com/jbergstroem) -
 **Johan Bergström** <bugs@bergstroem.nu>
 * [jhamhader](https://github.com/jhamhader) -
@@ -319,8 +323,6 @@ more information about the governance of the Node.js project, see
 **Michaël Zasso** <targos@protonmail.com>
 * [tellnes](https://github.com/tellnes) -
 **Christian Tellnes** <christian@tellnes.no>
-* [thefourtheye](https://github.com/thefourtheye) -
-**Sakthipriyan Vairamani** <thechargingvolcano@gmail.com>
 * [thekemkid](https://github.com/thekemkid) -
 **Glen Keane** <glenkeane.94@gmail.com>
 * [thlorenz](https://github.com/thlorenz) -

WORKING_GROUPS.md

@@ -21,7 +21,7 @@ back in to the CTC.
 * [Website](#website)
 * [Streams](#streams)
 * [Build](#build)
-* [Tracing](#tracing)
+* [Diagnostics](#diagnostics)
 * [i18n](#i18n)
 * [Evangelism](#evangelism)
 * [Roadmap](#roadmap)
@@ -81,17 +81,22 @@ Its responsibilities are:
 * Creates and manages build-containers.
 
 
-### [Tracing](https://github.com/nodejs/tracing-wg)
+### [Diagnostics](https://github.com/nodejs/diagnostics)
 
-The tracing working group's purpose is to increase the
-transparency of software written in Node.js.
+The diagnostics working group's purpose is to surface a set of comprehensive,
+documented, and extensible diagnostic interfaces for use by
+Node.js tools and JavaScript VMs.
 
 Its responsibilities are:
-* Collaboration with V8 to integrate with `trace_event`.
-* Maintenance and iteration on AsyncWrap.
-* Maintenance and improvements to system tracing support (DTrace, LTTng, etc.)
-* Documentation of tracing and debugging techniques.
-* Fostering a tracing and debugging ecosystem.
+
+* Collaborate with V8 to integrate `v8_inspector` into Node.js.
+* Collaborate with V8 to integrate `trace_event` into Node.js.
+* Collaborate with Core to refine `async_wrap` and `async_hooks`.
+* Maintain and improve OS trace system integration (e.g. ETW, LTTNG, dtrace).
+* Document diagnostic capabilities and APIs in Node.js and its components.
+* Explore opportunities and gaps, discuss feature requests, and address
+  conflicts in Node.js diagnostics.
+* Foster an ecosystem of diagnostics tools for Node.js.
 
 ### i18n