diff --git a/meetings/2016-12-07.md b/meetings/2016-12-07.md new file mode 100644 index 0000000..ba88ddf --- /dev/null +++ b/meetings/2016-12-07.md @@ -0,0 +1,313 @@ +# Node.js Foundation CTC Meeting 2016-12-07 + +## Links + +* **Audio Recording**: +* **GitHub Issue**: [CTC#43](https://github.com/nodejs/CTC/issues/43) +* **Minutes Google Doc**: + +* _Previous Minutes Google Doc_: + + + +## Present + +* Anna Henningsen @addaleax (CTC) +* Сковорода Никита Андреевич @ChALkeR (CTC) +* Colin Ihrig @cjihrig (CTC) +* Jeremiah Senkpiel @Fishrock123 (CTC) +* Josh Gavant @joshgav (observer/Microsoft) +* Michael Dawson @mhdawson (CTC) +* Brian White @mscdex (CTC) +* Ali Ijaz Sheikh @ofrobots (CTC) +* Jenn Turner @renrutnnej (observer/Node.js Foundation) +* Seth Thompson @s3ththompson (observer/Google) +* Michaël Zasso @targos (observer) +* Evan Lucas @evanlucas (CTC) +* Bradley Farias @Bmeck (TC39 / observer) +* Rich Trott @Trott (CTC) +* James M Snell @jasnell (CTC) + + +## Standup + +* Anna Henningsen @addaleax (CTC) + * NINA, Code & Learn +* Сковорода Никита Андреевич @ChALkeR (CTC): + * Looked up some ecosystem security-related things, nothing much. +* Colin Ihrig @cjihrig (CTC) + * NINA last week. Reviewing issues and PRs +* Evan Lucas @evanlucas (CTC) + * NINA and helping review/land some of the code and learn PRs +* Jeremiah Senkpiel @Fishrock123 (CTC): + * NINA, code&learn, Collab summit + * Node 7.2.1 release + * so much reviewing +* Josh Gavant @joshgav (observer/Microsoft): + * Node Interactive and post-conference processing +* Michael Dawson @mhdawson (CTC): + * NINA, code&learn, Collab summit + * adding octane to benchmark runs/results + * misc review/comments/lands + * process for allowing WGs more control over build jobs + * ongoing ABI stable module API work +* Brian White @mscdex (CTC): + * Reviewed PRs, commented on issues +* Ali Ijaz Sheikh @ofrobots (CTC): + * Node Interactive last week. Not much else. +* Jenn Turner @renrutnnej (observer/Node.js Foundation): + * No update, just observing. +* Seth Thompson @s3ththompson (observer/Google): + * At Node Interactive & vm neutrality summit + * Circulating the discussions with the V8 team. +* Michaël Zasso @targos (observer): + * Reviewed PRs and commented on issues. +* Bradley Farias @Bmeck (TC39 / observer): + * Met w/ v8 and google about various module topics +* Rich Trott @Trott (CTC): +* James M Snell @jasnell (CTC): + * Not present during the main part of the call, but… + * Node.js Interactive last week + * Landing a few PRs this week + * Continued work on HTTP/2 implementation + +--- + +## Agenda + +### nodejs/node + +* deps: upgrade npm to 4.0.2 [#9848](https://github.com/nodejs/node/pull/9848) + +### nodejs/node-eps + +* Initial version of eps for ABI-Stable-Module-API + [#20](https://github.com/nodejs/node-eps/pull/20) + +### nodejs/CTC + +* Moving `node-inspect` into core [#40](https://github.com/nodejs/CTC/issues/40) + +--- + +## Previous Meeting Review + +### nodejs/node + +* Revert "buffer: runtime deprecation of calling Buffer without new" + [#9529](https://github.com/nodejs/node/pull/9529) + +--- + +## Minutes + +### deps: upgrade npm to 4.0.2 [#9848](https://github.com/nodejs/node/pull/9848) + +@Fishrock123: New major, need to consider impact and when to land. May not need +to be in a Node.js major change. + +@mhdawson: Is it breaking? + +@Fishrock123: Yes, but really obscure edge cases AFAIK. + +@addaleax: Yes, it’s technically breaking but I don’t think it will break +anyone’s code. + +@evanlucas: Which version would we land on? + +@addaleax: npm plans to get 5.x release out in first quarter of 2017, so we may +be able to skip 4.x entirely. + +@Fishrock123: So question is whether to land in current 7.x branches. + +@evanlucas: I think they may have backported changes to version 3, but if it’s +not being maintained we may have to go to version 4. + +@Fishrock123: Bug fixing maintenance will continue, but no new features. + +@mhdawson: Question is what’s the advantage of being part of a 7.x release, as +opposed to waiting for 8.x. + +@Fishrock123 @addaleax: it should not be ported back to 6.x. + +@evanlucas: Should we ship with both 3 and 4? + +People can update npm themselves. + +@addaleax: I’ve heard that npm doesn’t feel strongly about getting it in 7.x, +but would like everyone to move to 4. + +@addaleax: I’m okay to land in 7.x. Very few cases where code will be broken. + +**Next steps**: + +* Take back to GitHub for more discussion. + + +--- + +### Moving `node-inspect` into core [#40](https://github.com/nodejs/CTC/issues/40) + +See also +[nodejs/diagnostics#67](https://github.com/nodejs/diagnostics/issues/67). + +@Trott: Old debugger protocol and CLI debugger is going away. + +@ofrobots: Deprecating old CLI debugger, can build a new CLI debugger based on +new inspector protocol. + +Issue for removal of V8 Debug API: + +Questions are: + +* Do we want a CLI Debugger in core itself? +* Do we want it separate from core, but shipped with default distribution, like + npm? +* Don’t include in distribution, but make available via package managers. + +Some feel it should be in core, but some concern because current implementation +hasn’t been maintained. + +@Fishrock123: What would bundling look like? E.g. Would `node inspect script.js` +work, or would one use `node-inspect` installed globally? + +@joshgav: Could bundle in /deps and include abstraction or #ifdef and build flag +guard where `node debug` is now. + +@ofrobots: We have flexibility if we want to bundle it. + +@joshgav: We believe it should be in the Foundation, but question is should it +be somehow part of core. If any are opposed to it even being in the Foundation +please speak up. + +@addaleax: Informal Twitter survey said about 20% of respondents use it, and +also that many don’t even know about it. + +@evanlucas: We should at least bundle it. + +@Fishrock123: Since debugging story for Node is still maturing, removing it +wouldn’t be a great move. + +[Discussion of SIGUSR1 activating inspector instead of debugger, but that seems +to be tangential to this.] + +@Fishrock123: Any reasons for not bundling it? + +@evanlucas: Some have brought up that it could get stale if *not* bundled. If +it’s bundled than we guarantee it works out of the box. + +@mhdawson: Sometimes it’s not easy to get it, having some tools available by +default is important. + +@mscdex: Is it the same API as the previous debugger? + +@bmeck: Some minor differences due to Console API wrapper, but that’s it AFAIK. + +@jkrems: If it’s bundled then it would be hard to remove it, perhaps don’t want +it in an LTS. + +@trott: If it’s like npm then that’s less of a concern. + +@bmeck: Some embedders may have concerns, need their opinion. + +@evanlucas: Seek more community input? + +@Fishrock123: Since we already have `node debug` and `node --inspect` I think we +don’t really have much of a choice. + +@jkrems: Argue against aliasing `node debug` itself, because people may need it +to connect remotely to older versions. + +@joshgav: Need to clarify how we support connecting from a newer version of Node +to an older version, perhaps factor out the old debugger into a userland module +for that use case. + +@addaleax: We seem to have consensus that this should be in/bundled in core in +some form. + +@Fishrock123: Need to also deprecate old debugger. @ofrobots said we might be +able to delay removal from V8, otherwise we might have to deprecate it now in +7.x. + +@trott: Anything else needed for node-inspect? + +@jkrems: Currently it’s optimized to be a replacement (i.e. in /lib), but if it +would be bundled like npm it could be refactored into multiple files etc. + +That wouldn’t effect update-ability via npm. + +@Fishrock123: Even if tightly coupling (in /lib) we could still break into +multiple files. + +@jkrems: True, but it’s easier to test if it matches the current impl. + +Seems to be rough consensus that if it would be bundled in core it would be like +npm (in /deps). + +@trott: Goal is that it be available to users in some way. + +From YouTube: If it’s not bundled in default distribution would not be allowed +to be installed in production systems. + +@addaleax: Even if we bundle it as a separate thing like npm could be built into +the executable. + +Next step is to create a PR on core pulling it into /deps and get review and +thoughts. @jkrems to work on this. + +@joshgav to open request for adding to Foundation in TSC. + +**Next steps**: + +* @jkrems to open PR to put in /deps in core. +* @joshgav to open issue in nodejs/tsc to bring into Foundation. +* Deprecate old debugger. + + +--- + +### Initial version of EP for ABI-Stable-Module-API [#20](https://github.com/nodejs/node-eps/pull/20) + +@mhdawson: Looking for more thoughts and comments. + +One option is to point from EP to actual repo with prototypes, which would +reflect current state of API. + +@s3ththompson: V8 team is reviewing, will create issue in the ABI repo. + +@jasnell: Anyone saying it’s just the wrong way to go? + +@mhdawson: No. Someone suggested nbind, that might parallel the FFI work. + +V8 team is also working on a FFI to address native modules issues. Plan is to +review NAPI and FFI in January-Feb-March time frame. + +@s3ththompson: These could be complementary. + +@mhdawson: So ask from CTC is can we land as is, or what is needed? + +@Fishrock123: Any problem with landing as draft? + +@mhdawson: I don’t think so, but wanted CTC approval since there was one +objection in thread. + +**Next steps**: + +* No objections from those present. Michael will leave open for a few more days + and then land if no further objections. + + +--- + +## Q/A on public channels + +None. + + +--- + +## Upcoming Meetings + +* CTC: 2016-Dec-14, 2000 UTC (12pm Pacific) +* TSC: 2016-Dec-15, 2000 UTC (12pm Pacific) +