From 3f1f3c99e29d417e11c61aa127da711616728d27 Mon Sep 17 00:00:00 2001 From: James M Snell Date: Mon, 7 Nov 2016 08:20:56 -0800 Subject: [PATCH] Move CTC meeting minutes into nodejs/CTC repo --- meetings/2015-10-28.md | 276 +++++++++++++++++++++++++++++++++ meetings/2015-11-04.md | 65 ++++++++ meetings/2015-11-11.md | 136 +++++++++++++++++ meetings/2015-12-02.md | 83 ++++++++++ meetings/2015-12-16.md | 164 ++++++++++++++++++++ meetings/2016-01-06.md | 216 ++++++++++++++++++++++++++ meetings/2016-01-20.md | 337 +++++++++++++++++++++++++++++++++++++++++ meetings/2016-01-27.md | 295 ++++++++++++++++++++++++++++++++++++ meetings/2016-02-03.md | 223 +++++++++++++++++++++++++++ meetings/2016-02-10.md | 167 ++++++++++++++++++++ meetings/2016-02-17.md | 240 +++++++++++++++++++++++++++++ meetings/2016-05-04.md | 192 +++++++++++++++++++++++ meetings/2016-06-15.md | 174 +++++++++++++++++++++ meetings/2016-06-22.md | 151 ++++++++++++++++++ meetings/2016-06-29.md | 187 +++++++++++++++++++++++ meetings/2016-07-06.md | 150 ++++++++++++++++++ meetings/2016-07-13.md | 236 +++++++++++++++++++++++++++++ meetings/2016-07-20.md | 202 ++++++++++++++++++++++++ meetings/2016-07-27.md | 237 +++++++++++++++++++++++++++++ meetings/2016-08-03.md | 336 ++++++++++++++++++++++++++++++++++++++++ meetings/2016-08-10.md | 281 ++++++++++++++++++++++++++++++++++ meetings/2016-08-17.md | 300 ++++++++++++++++++++++++++++++++++++ meetings/2016-08-24.md | 328 +++++++++++++++++++++++++++++++++++++++ meetings/2016-08-31.md | 315 ++++++++++++++++++++++++++++++++++++++ meetings/2016-09-07.md | 245 ++++++++++++++++++++++++++++++ meetings/2016-09-14.md | 153 +++++++++++++++++++ meetings/2016-09-21.md | 218 ++++++++++++++++++++++++++ meetings/2016-09-28.md | 303 ++++++++++++++++++++++++++++++++++++ meetings/2016-10-05.md | 312 ++++++++++++++++++++++++++++++++++++++ meetings/2016-10-12.md | 157 +++++++++++++++++++ meetings/2016-10-19.md | 202 ++++++++++++++++++++++++ meetings/2016-10-26.md | 151 ++++++++++++++++++ 32 files changed, 7032 insertions(+) create mode 100644 meetings/2015-10-28.md create mode 100644 meetings/2015-11-04.md create mode 100644 meetings/2015-11-11.md create mode 100644 meetings/2015-12-02.md create mode 100644 meetings/2015-12-16.md create mode 100644 meetings/2016-01-06.md create mode 100644 meetings/2016-01-20.md create mode 100644 meetings/2016-01-27.md create mode 100644 meetings/2016-02-03.md create mode 100644 meetings/2016-02-10.md create mode 100644 meetings/2016-02-17.md create mode 100644 meetings/2016-05-04.md create mode 100644 meetings/2016-06-15.md create mode 100644 meetings/2016-06-22.md create mode 100644 meetings/2016-06-29.md create mode 100644 meetings/2016-07-06.md create mode 100644 meetings/2016-07-13.md create mode 100644 meetings/2016-07-20.md create mode 100644 meetings/2016-07-27.md create mode 100644 meetings/2016-08-03.md create mode 100644 meetings/2016-08-10.md create mode 100644 meetings/2016-08-17.md create mode 100644 meetings/2016-08-24.md create mode 100644 meetings/2016-08-31.md create mode 100644 meetings/2016-09-07.md create mode 100644 meetings/2016-09-14.md create mode 100644 meetings/2016-09-21.md create mode 100644 meetings/2016-09-28.md create mode 100644 meetings/2016-10-05.md create mode 100644 meetings/2016-10-12.md create mode 100644 meetings/2016-10-19.md create mode 100644 meetings/2016-10-26.md diff --git a/meetings/2015-10-28.md b/meetings/2015-10-28.md new file mode 100644 index 0000000..5efe944 --- /dev/null +++ b/meetings/2015-10-28.md @@ -0,0 +1,276 @@ +# Node Foundation CTC Meeting 2015-10-28 + +## Links + +* **Audio Recording**: https://soundcloud.com/node-foundation/ctc-meeting-2015-10-28 +* **GitHub Issue**: https://github.com/nodejs/node/issues/3561 +* **Minutes Google Doc**: +* _Previous Minutes Google Doc: _ + +## Present + +* Rod Vagg (CTC) +* Brian White (CTC) +* James Snell (CTC) +* Chris Dickinson (CTC) +* Ben Noordhuis (CTC) +* Jeremiah Senkpiel (CTC) +* Trevor Norris (CTC) +* Alexis Campailla (CTC) +* Mikeal Rogers (observer) +* Shigeki Ohtsu (CTC) +* Seth Thompson (observer) +* Bert Belder (CTC) +* Fedor Indutny (CTC) +* Ben Noordhuis (CTC) +* Colin Ihrig (CTC) + +## Agenda + +Extracted from **tsc-agenda** labelled issues and pull requests in the nodejs org prior to meeting. + +### nodejs/node + +* Load JSON-LD in the same way as JSON [#3502](https://github.com/nodejs/node/pull/3502) +* fs: decode filenames using UTF-8 in fs.watch [#3401](https://github.com/nodejs/node/pull/3401) +* WG: Considering a new HTTP WG [#3214](https://github.com/nodejs/node/issues/3214) + +## Minutes + +### Review of previous meeting + +* governance: add new collaborators #VIII [#3472](https://github.com/nodejs/node/issues/3472) +* detect "full-icu" module [#3460](https://github.com/nodejs/node/issues/3460) +* WG: Considering a new HTTP WG [#3214](https://github.com/nodejs/node/issues/3214) +* node: deprecate public access to `process.binding` [#2768](https://github.com/nodejs/node/pull/2768) +* node: make listen address configurable [#3316](https://github.com/nodejs/node/pull/3316) + +### Standup + +* Rod Vagg (CTC): Traveling, rc for v5.x, going to put another rc out today, comfortable with it getting released tomorrow. If it slips we’ll put it off until next week. Just need to do more smoke testing on this. +* Brian White (CTC): Not a whole lot this week — triaging, responding to issues. +* James Snell (CTC): Getting HTTP parser up to v2.6; getting 4.2.2 LTS update ready to go. open issue on LTS repo, would love eyes on it, to verify that the commits going into 4.2.2 look good. (https://github.com/nodejs/LTS/issues/50) working with Miles on getting CITGM updated. +* Chris Dickinson (CTC): Some silly build stuff +* Jeremiah Senkpiel (CTC): Not much — computer was dead since last Friday, ): but repaired now. +* Trevor Norris (CTC): Bugs and issues — couple of outstanding PRs around asyncwrap, one done at Fedor’s request to make AsyncWrap public, in order to make JSStream class public +* Alexis Campailla (CTC): Meetings; first API WG meeting, defining scope of the work for the WG, we want to address engine abstraction and native module API and some performance issues; small work in CI to add diagnostics; progress on module build service, going to post finding soon to get feedback +* Mikeal Rogers (observer): getting a lot of interest on a certification program for node, for alternative implementations, looking at notes for API WG (thanks for taking great notes! that was awesome) I reached out to a few people that may contribute as well +* Seth Thompson (observer): No updates this week. +* Bert Belder (CTC): nothing noteworthy +* Ben Noordhuis (CTC): Fixed debugger bugs, reviewed a lot of pull requests. +* Colin Ihrig (CTC): Trying to help out with issue tracker, anticipate in another week ½ I should have significantly more time to work on core. + +### Load JSON-LD in the same way as JSON [#3502](https://github.com/nodejs/node/pull/3502) + +* adds .jsonld files to require.extensions so that they’d load using json loader + +Rod: I raised this to CTC. I see this as a slippery slope, adding anything more to require.extensions. I don’t see how this won’t turn into XML — turns into bloat in formats that folks want to support. My preference would be to let the ecosystem figure this out and let folks write their own JSON loaders. + +Jeremiah: also probably belongs in npm + +James: .jsonld is just a json file with a special syntax internally. I have a module that loads it. It’s very easy to work around. Rename the file to use a json extension. I don’t see the harm in landing it, but if we don’t want to go that route, + +Mikeal: is the patch to add the extension or to give you your own serializer (extension) + +Bert: It seems harmless, but 6 months from now what if someone shows up and says “hey you’re not validating it properly” and then we have to add a validator … I’m very sensitive to slippery slope argument + +Alexis: Is it a different syntax? + +Bert: is every json document a valid jsonld document? + +James: no. + +Mikeal: we’re using a parser from npm, are we going to get a war between parsers, swapping them out? + +James: this doesn’t do any special parsing for jsonld, it just aliases json and uses the existing process. + +Trevor: the problem is what it opens us up to. invariably this leads to more PRs. this patch I don’t have a problem with, but I have a problem with this kind of patch in the future + +Bert: I think we’re reaching consensus here, which is: reject this patch. is anyone here strongly in favor. + +Ben: not in favor. one argument is jsonld is now a standard. but I too am sensitive to the slippery slope argument, so I’m perfectly fine with rejecting it. + +James: when rejecting it, it would be worthwhile to note how to work around it. I can do this. + +Jeremiah: require.extensions is not going to change anytime soon, so folks can write their own. + +Bert: I think we can go to the next issue. + +### fs: decode filenames using UTF-8 in fs.watch [#3401](https://github.com/nodejs/node/pull/3401) + +See also [#3519](https://github.com/nodejs/node/issues/3519) + +Bert: this is Ben’s issue. + +Ben: I wouldn’t say it’s my issue, but I’ve been involved +the thing is that filenames are frequently (but not always) utf8, the problem is now that node in one or two places it doesn’t encode utf8 [Ben, post meeting addition: For background: I thought we had some file logic baked into node::Environment and the dtrace/etw/lttng/systemtap subsystems but turns out that's not the case.] + +Bert: where else are we encoding differently? + +Ben: I can answer this in a few seconds. At least, I think there are more places. Maybe I’m mistaken, also a possibility! + +Jeremiah: I think someone else said it was only fs.watch too. + +Bert: I’ve seen the discussion but I haven’t commented. I think there’s a problem with assuming that all files are all utf8, but it seems inconsequential to assume this everywhere but this one place + +Ben: this is not the best issue to link to, I agree it’s inconsistent to do utf8 in most places and latin1 in only one place. There’s a link to another issue 3519. my beef with the PR is not that it’s a terrible fix, it’s more that decoding to utf8 is not always the right thing to do because not all fs are utf-8. If we’re going to do this it has to be a semver major, and if we’re going to do a semver major, then it may as well be a full fix, which I’ve outlined in 3519. + +Bert: there’s actually some discussions we need to have around these things. Your suggestion is to not land this PR, and instead fix this the right way. Do you think it’s likely that 3519 will see attention any time soon? + +Ben: It’s on my todo list. I should mention that the way node deals with file names has been a thorn in my side for a long time now, I’ve been planning to do something about it for a long time, so take this as you will. + +Bert: my question is: do we take this PR now, ahead of + +Bert: customizable decoding + +Mikeal: is the other one going to be a breaking change? + +Ben: yes + +Bert: or it could be a bugfix? + +Mikeal: so it would make sense to buffer as many changes around that as possible. + +Jeremiah: we could land the semver-major fix on master which would go into 6.x, then if we have time before 6.x we could do the proper fix. maybe that keeps us from fixing it entirely though? + +Ben: that’s my problem, it’s a bandaid that lets us truck on for a another couple of years. + +James?: I don’t really like quick fixes, but … + +Trevor: on the fs doc page, a lot of those calls reference the system level call, on unix do those use utf8 + +Ben: how do you mean? + +Trevor: for example, stat, first arg is char* pathname, if i were to take a utf8 string and read that in… what encoding does it use? + +Ben: syscall is agnostic. kernel treats as string of bytes. in node, we call fs.stat in javascript, string is decoded to utf8, then passed on to the kernel. + +Trevor: if i have a file that’s latin1, I’d have to turn that into a buffer as a binary buffer then tostring it to a utf8 string in order for the file to be open? + +[multiple people are talking] + +Ben: yes. + +Ben: sometimes it’s not possible to open files with funny characters in their names. + +Trevor: if there were a file with invalid utf8 characters it’d be impossible to open those, right? + +Ben: yep. + +James: I’m not a fan of the quick fix. I am okay with incremental so long as the larger task gets done, but … + +Bert: I am in favor of the quick fix, it restores consistency in the way node does things. practically speaking, almost all fs are going to be utf-8. it fixes the problem where fs.watch tells you “hey a file changed” but you go to look and the file’s not there due to the encoding scheme. I’d like to make a little improvement. the problem has been known since at least 2011, and we’ve never gotten around to it. I would not be surprised if it takes another 4 years for someone to take a stab at it. + +Brian: is it possible to get the user’s LOCALE and convert to that before sending it off? + +Ben: that’s worse than what we have now. + +James: the LOCALE often lies. + +Bert: are we going to land the patch to fs.watch? I’d like to have a quick references. + +Trevor: it’s not going to land in 5, we could leave it open until near v6 and land it then if no one is able to get around to the full fix. there’s 5-6 months between 5 and 6… + +Rod: that sounds like a nice compromise. + +### WG: Considering a new HTTP WG [#3214](https://github.com/nodejs/node/issues/3214) + +Rod: I left this on because I thought it’d be nice to get a report from the WG on how it went. + +James: [cd: I am missing folk here]: Jeremiah, Eran Hammer, Doug Wilson, Myles Borins Brian White, Patrick Mueller, and myself. + +We talked about the charter. Looking into what improvements can be made to better support the ecosystem. Making existing impl hookable so that modules could swap out parts of the implementation with their own. Like replacing the parser, or header specific handling. The charter covers that aspect of it, but emphasizes that existing systems are not broken. We have a number of issues that we’ve created to start discussing these. I’ll get these into the doc. + +That’s the short version. Still really early to tell what all will come of it and what kind of schedule it’ll be on. 5th, at [cd: TIME?] +We’ll be drawing up a charter and bringing it back to this group. + +Any other questions? + +Rod: could we get a report on the API WG? + +Trevor: the discussion was mainly around the native api. it went in a direction I wasn’t expecting. I explained my JS API proposal, then it went into a module discussion. ABI compat is straight out, it went in the direction of NAN (API compat, but occasional recompiles). Some discussion arose around abstracting node, like v8 completely. to replace with another VM. How do you handle specific difference like features that are available in one vm or another? or JS features that are/aren’t available between VMs. To target all vms, you end up having to use ES5. I was kind of losing where they were going with it. there are a lot of smart people. We’ll just have to have a discussion about feasibility. + +Ben: Was there any talk about who’s going to do the actual work? + +Trevor: No — it was more theoretical. It was more like the ES committee — develop features then say “go make these.” IF I bring it up I’m sure I can get some solid answers. + +Alexis: I’m trying to push for the Chakra folks to do some of this work. + +Mikeal: [cd: sorry, I missed this.] + +Rod: What companies are involved? Did MS show up? + +Trevor: Yes, I think so. JXCore, IBM was there, can’t remember offhand. + +Bert: JXCore is also secretly MS? + +Alexis: Not a secret! They’re on contract for an industrial IoT project. + +Alexis: IBM was there, Nodesource. + +Mikeal: Looking for someone from samsung’s jerryscript team to join. + +Trevor: My initial proposal was to get something usable. I’ll be out of there if it turns into WASM — if it blows up in size. + +Mikeal: The whole point is to be smaller than the current API, right? + +Bert: Well, not smaller, but … let’s not talk about technical issues + +Alexis: We’ve discussed multiple approaches, and we can tackle the problem from multiple sides. Trevor is tackling it by reducing the size of core. The approach I want to take is FFI interface into native modules. All of these approaches can help us tackle this huge beast into a manageable problem. They’re not competing solutions. + +Bert: We want to avoid scope creep. If the WG comes up with a HUGE proposal with 20 points of view, then no one will ever go do it. + +Trevor: I want to simplify the JS API, and get it to a point where all of the existing api can sit on top of it. If someone wants to do the work of replacing V8, they’ll have a clean entry point into the JS. And then write a set of compliance tests that specify what every entry point does. Writing a bunch for native code without JS tests to back it up would be futile. + +Bert: Restricting it to API design, that in theory, the sort of design goal, is for the API to be sufficient for Node to use. + +Alexis: This would include the native module api? + +Rod: It sounds like HTTP attacked charter first, maybe the API WG needs to do the same, to combat growth of scope. Maybe anyone else on this call that wants to could join and try to define scope? Is there another call scheduled, Trevor? + +Trevor: we’re still collecting times. I’ll mention the ctc in the issue. + +Rod: we should make a new @ctc GH group. + +Bert: which is going to be more fun? + +Rod: The CTC + +Bert: when are we going to split up? + +Rod: Mikeal is organizing another meeting. + +Mikeal: It’s tomorrow at this time slot. + +### node-gyp: Windows users are not happy. [node-gyp#629](https://github.com/nodejs/node-gyp/issues/629) + + +Jeremiah: Do we want to talk about the windows issue? + +Rod?: it kind of contains all of the windows problems. + +Alexis: I was asking about guidance on this. + +Rod: there’s a strategy of giving folks a place to vent, keeping it from spilling over elsewhere. Without this issue, it might explode into a bunch more issues. + +Alexis: We’re working on a module build service. The other thing is that MS is going to release a smaller SKU of the compiler, that might be able to be included with node-gyp. + +Rod: Next visual studio is going to be shipping with clang. + +Trevor: Yes for AST stuff. [cd: might have gotten this wrong] + +Rod: Alexis, you should post in there, but I think it’s going to always catch folks googling for the problem. I’m not sure you can resolve it by closing or locking it. Folks will go there and not see a proper resolution. + +Mikeal: make sure there are issues for everything in the thread, then close and lock. Make sure there are resolutions (even if it’s “move hte conversation”). + +Rod: I’m happy for Alexis to take the lead on this. + +Rod: Maybe change the title to “Windows users are happy?” + +Alexis: Maybe change to “Unix users are unhappy.” + +Rod: that’d be an epic troll. + +## Next Meeting + +November 4, 2015 diff --git a/meetings/2015-11-04.md b/meetings/2015-11-04.md new file mode 100644 index 0000000..1c83d45 --- /dev/null +++ b/meetings/2015-11-04.md @@ -0,0 +1,65 @@ +# Node Foundation CTC Meeting 2015-11-04 + +## Links + +* **Audio Recording**: https://soundcloud.com/node-foundation/ctc-meeting-2015-11-04 +* **GitHub Issue**: https://github.com/nodejs/node/issues/3660 +* **Minutes Google Doc**: +* _Previous Minutes Google Doc: _ + +## Present + +* Rod Vagg (CTC) +* James Snell (CTC) +* Chris Dickinson (CTC) +* Ben Noordhuis (CTC) +* Jeremiah Senkpiel (CTC) +* Trevor Norris (CTC) +* Alexis Campailla (CTC) +* Mikeal Rogers (observer) +* Shigeki Ohtsu (CTC) +* Seth Thompson (observer) +* Bert Belder (CTC) +* Fedor Indutny (CTC) +* Ben Noordhuis (CTC) +* Colin Ihrig (CTC) + +## Agenda + +Extracted from **ctc-agenda** labelled issues and pull requests in the nodejs org prior to meeting. + +### nodejs/node + +* deps: backport 9da3ab6 from V8 upstream [#3609](https://github.com/nodejs/node/pull/3609) + +## Minutes + +### Review of previous meeting + +* Load JSON-LD in the same way as JSON [#3502](https://github.com/nodejs/node/pull/3502) +* fs: decode filenames using UTF-8 in fs.watch [#3401](https://github.com/nodejs/node/pull/3401) +* WG: Considering a new HTTP WG [#3214](https://github.com/nodejs/node/issues/3214) +* node-gyp: Windows users are not happy. [node-gyp#629](https://github.com/nodejs/node-gyp/issues/629) + +### Standup + +* Rod: 0.12/0.10 build infra +* Michael: catching up from being away +* Trevor: reviewing PRs +* James: v4.2.2 + +### deps: backport 9da3ab6 from V8 upstream [#3609](https://github.com/nodejs/node/pull/3609) + +Discussed the semver for this feature, should it be patch or minor? LTS WG has agreed to land this patch but are unsure whether it should bump minor. Discussed some of the points in the issue. + +Trevor: this issue seems to have made it in thanks to a lot of noise made by users, is this going to be a factor in considering future changes for LTS? + +Discussed this topic, agreeing that we shouldn’t be held captive to bike-shedding. + +Bert: would be surprised if this landed as semver-minor, it’s clearly a feature addition. + +Trevor: can we stash this and wait to see what else might be landable—can we expect to have these conversations in the future? + +## Next Meeting + +November 11th, 2015 diff --git a/meetings/2015-11-11.md b/meetings/2015-11-11.md new file mode 100644 index 0000000..de23a81 --- /dev/null +++ b/meetings/2015-11-11.md @@ -0,0 +1,136 @@ +# Node Foundation CTC Meeting 2015-11-11 + +## Links + +* **Audio Recording**: https://soundcloud.com/node-foundation/ctc-meeting-2015-11-11 +* **GitHub Issue**: https://github.com/nodejs/node/issues/3777 +* **Minutes Google Doc**: +* _Previous Minutes Google Doc: _ + +## Present + +* Rod Vagg (CTC) +* James Snell (CTC) +* Ben Noordhuis (CTC) +* Jeremiah Senkpiel (CTC) +* Trevor Norris (CTC) +* Mikeal Rogers (observer) +* Fedor Indutny (CTC) +* Ben Noordhuis (CTC) +* Colin Ihrig (CTC) +* Steven R Loomis (observer?) +* Brian White (CTC) +* Michael Dawson (observer) + +## Agenda + +Extracted from **ctc-agenda** labelled issues and pull requests in the nodejs org prior to meeting. + +* Rediscuss if error message changes are semver-major [#3776](https://github.com/nodejs/node/issues/3776) +* V8 working group [#3741](https://github.com/nodejs/node/issues/3741) + +### Standup + +* Rod Vagg: Way too busy, tz lagged. Nodefest JP (with translation)- good community event, large turnout. Ripe for node expansion. Hung out with Shigeki and Yosuke. 0.12 build stuff, Jenkins down but coming back up. Good changes, but put behind with 0.10/0.12 stuff +* James Snell: triaging issues, not a whole lot more beyond 4.2.2. CITGM with Myles, landing PRs. +* Ben Noordhuis: Fixed bug in cluster module, libuv minor work, reviewed lots of PRs/issues. Looking into node-gyp - lots of confusion around python requirement on Windows. Idea: embed in python interpreter, but complicated adventure. +* Jeremiah Senkpiel: Issue/PR work. 5.1.0 release work (delayed). Helping potential new collaborators get involved. +* Trevor Norris: Submitted patch for microbenchmark improvements, removing `Object::Set()` in C++. Helping community members get involved. +* Mikeal Rogers: Rewriting policies. Last-month contributors script, metrics. +* Fedor Indutny: v8 stuff. Tool for postmortem inspection of nodejs process using lldb on linux and osx. Review, requests. +* Colin Ihrig: Reviews, PRs. Opened a very popular PR on cluster suicide. +* Steven R Loomis: Unicode conferences and meetings for the last few weeks, not a lot to report other than moving the iojs language groups to node.js versions. (#2525) +* Brian White: reviewing PRs, triaging, commenting on issues +* Michael Dawson: PR for AIX based on comments, test issues, ppc release machines added to CI, work with Stefan on FIPS PR (unique value - equivalent coverage with FIPS enabled/disabled, and better error message). + +### Rediscuss if error message changes are semver-major [#3776](https://github.com/nodejs/node/issues/3776) + +Mikeal: do not guarantee that error messages don’t change. v8 changes error messages. don’t [shouldn’t] check message text. + +Rod: Don’t think we can make an assumption that this is not done. + +Mikeal: this is a lot of messages changing all at once + +Rod: What about localized messages? (when they change) + +Jeremiah: Localized messages have an ID so that shouldn’t be an issue + +Trevor: if v8 doesn’t internationalize, we shouldn’t internationalize ours + +James: Looking at i18n [l10n] of v8’s messages… comes down to whether ICU will be there by default + +Mikeal: should we be attaaching IDs to messages now? + +_: Error code (such as in Visual Studio) makes it very googleable which is a great help + +Steven: that’s one of the benefits.. + +Trevor: how do you guarantee uniqueness? + +Mikeal: attach a unique code.. + +Rod: Have 2 files that collect the codes. + +Trevor: Pass a function name and string..? + +Rod: … consider this for our API + +Mikeal: don’t know how we can keep these from changing in the context of internationalization + +Rod: But they are not internationalized yet. Can say now, don’t depend on these saying a certain thing. + +Mikeal: we haven’t been aware of libuv’s changes , would need to keep track of libuv’s changes. + +Michael: will this make it hard to fix typos in messages? Would be nice to correct instead of leave the message as is. + +Jeremiah: If people need to check the text for something other than tests, not assigning a unique enough type of error. Seems like bad practice. + +Rod: people do bad things already… + +Jeremiah: make sure people don’t *need* to do these things for legitimate reasons + +Rod: Not fine with semver-major if we decide it’s not a change in general. + +Steven: make it major to put people on notice… ? ids may be good and helpful in general? + +Mikeal: semver-major could make people think they can depend on message text …… hold off on any text changes until ID in place? + +Mikeal: would not accept this in LTS. Question is, would we accept it for 5? + +Rod: policy could say: “will accept changes as semver-patch, but don’t put them into LTS” + +Mikeal: make it semver-minor, consider it a feature. … get this out as Canary (master) … leave tagged + +### V8 working group [#3741](https://github.com/nodejs/node/issues/3741) + +Ben: place to put v8 documentation + +Jeremiah: make sure that some v8 knowledge stays among the core collaborators + +Rod: Julien’s concern is around reducing exposure to v8 + +Michael: Want to involve more people in v8 + +Rod: The other way, a separate WG allows people to find the right people + +Jeremiah: Documentation (of v8) + +Rod: no firm objections + +Steven: Have WG charter include disseminating knowledge/processes around v8? + +Rod: WG allows a good place to do this. + + +### ICU data - ±1 on approach? +[#3460](https://github.com/nodejs/node/issues/3460) ? srl + +… “move ahead, open PR, people can discuss.. mark as experimental so that people don’t depend on it” + +[Chris is taking over note-taking.] + +Rod: Take this to GitHub so we can have a proper discussion + +## Next Meeting + +November 18th, 2015 diff --git a/meetings/2015-12-02.md b/meetings/2015-12-02.md new file mode 100644 index 0000000..aaf3357 --- /dev/null +++ b/meetings/2015-12-02.md @@ -0,0 +1,83 @@ +# Node Foundation CTC Meeting 2015-12-02 + +## Links + +* **Audio Recording**: https://soundcloud.com/node-foundation/ctc-meeting-2015-12-02 +* **GitHub Issue**: https://github.com/nodejs/node/issues/4115 +* **Minutes Google Doc**: +* _Previous Minutes Google Doc: _ + +## Present + +* Rod Vagg (CTC) +* James Snell (CTC) +* Ben Noordhuis (CTC) +* Jeremiah Senkpiel (CTC) +* Trevor Norris (CTC) +* Mikeal Rogers (observer) +* Fedor Indutny (CTC) +* Colin Ihrig (CTC) +* Steven R Loomis (observer) +* Brian White (CTC) +* Michael Dawson (observer) +* Alexis Campailla (CTC) +* Bert Belder (CTC) + +## Agenda + +Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +### nodejs/node + +* tools: change tick processor install path [#4021](https://github.com/nodejs/node/pull/4021) +* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) +* Potential Licensing issues with npm [#3959](https://github.com/nodejs/node/issues/3959) +* Joyent Copyright still in header of many files [#3926](https://github.com/nodejs/node/issues/3926) +* doc: update irc channels to point to #node.js and #node-dev [#2743](https://github.com/nodejs/node/pull/2743) + + +### Standup + +* Rod Vagg: Catching up from some time off, preparing for security releases tomorrow. +* Ben Noordhuis: Pull requests and bug reports. +* Jeremiah Senkpiel: Large refactoring of timers, general project stuff—PRs and issues, spinning up the CI WG, trying to do more onboarding. +* Trevor Norris: PR review & merging, not too much. +* Mikeal Rogers: Prep for board meeting, new events page on website. +* Fedor Indutny: PR review, fixing fsevents bug in libuv +* Colin Ihrig: Usual issues & PRs +* Brian White: landed a few PRs, commented on issues +* Michael Dawson - Addition of FIPS tests to regression job and some ongoing FIPs related work, still trying to line up AIX machines, investigation with team on some failures on AIX, scheduled next benchmarking meeting, hoping to add charts for initial footprint benchmark, adding other build team members to softlayer/osu environments. +* Alexis Campailla: some build stuff, further investigation into native module build service +* Bert Belder: ? + + +## Review of last meeting + +* Re-discuss if error message changes are semver-major [#3776](https://github.com/nodejs/node/issues/3776) + +## tools: change tick processor install path [#4021](https://github.com/nodejs/node/pull/4021) + +* Ben: Matthew Loring from google has been working on this but has found an npm package with the name “node-tick-processor” + +* Discussed how we should deal with potential node core tooling that already shares a same name on npm. + +## Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) + +1. Potential Licensing issues with npm [#3959](https://github.com/nodejs/node/issues/3959) +2. Joyent Copyright still in header of many files [#3926](https://github.com/nodejs/node/issues/3926) + +* Rod outlined the approach he came up with in https://github.com/nodejs/node/issues/3979 for seeking legal input from the board (via whatever means they want) on (1) the head LICENSE file and (2) copyright and license blocks at the top of files and (3) the npm licensing issues raised in #3959. + +* Group agreed to move forward with the approach and to allow Rod and Mikeal to tune the wording before handing off. + +## doc: update irc channels to point to #node.js and #node-dev [#2743](https://github.com/nodejs/node/pull/2743) + +* No objections to renaming to #node-dev + +## TSC meeting tomorrow + +Briefly discussed the meeting tomorrow in this timeslot. Admitting libuv to the foundation as an incubator project. + +## Next Meeting + +December 9th, 2015 diff --git a/meetings/2015-12-16.md b/meetings/2015-12-16.md new file mode 100644 index 0000000..0ad4603 --- /dev/null +++ b/meetings/2015-12-16.md @@ -0,0 +1,164 @@ +# Node Foundation CTC Meeting 2015-12-16 + +## Links + +* **Audio Recording**: https://soundcloud.com/node-foundation/ctc-meeting-2015-12-16 +* **GitHub Issue**: https://github.com/nodejs/node/issues/4309 +* **Minutes Google Doc**: +* _Previous Minutes Google Doc: _ + +## Present + +* James Snell (CTC) +* Trevor Norris (CTC) +* Colin Ihrig (CTC) +* Brian White (CTC) +* Michael Dawson (observer) +* Alexis Campailla (CTC) +* Bert Belder (CTC) +* Chris Dickinson (CTC) +* Ali Ijaz Sheikh (observer) +* Shigeki Ohtsu (CTC) +* Seth Thompson (observer) +* Steven Loomis (observer) +* Mikeal Rogers (observer) +* Jeremiah Senkpiel (CTC) +* Rod Vagg (CTC) + +## Agenda + +Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +### nodejs/node + +* Discussion: OpenSSL 1.1.0 planning [#4270](https://github.com/nodejs/node/issues/4270) +* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) +* Potential Licensing issues with npm [#3959](https://github.com/nodejs/node/issues/3959) +* Joyent Copyright still in header of many files [#3926](https://github.com/nodejs/node/issues/3926) + +### nodejs/LTS + +* Discuss possibility of adjusting LTS schedule for better alignment with V8 schedule [#62](https://github.com/nodejs/LTS/issues/62) +* AsyncWrap for LTS Argon [#59](https://github.com/nodejs/LTS/issues/59) + + +### Standup + +* James Snell (CTC) — Node interactive, looking at PRs, i18n +* Trevor Norris (CTC) — Been sick, some review +* Colin Ihrig (CTC) — Node interactive, reviewing issues and PRs, yesterday started 5.3.0 release (held up to issue with debugging), am process of releasing 5.3.0 right now +* Brian White (CTC) — Submitted PRs, commenting on issues and PRs +* Michael Dawson (observer) - Node interactive - catching up +* Alexis Campailla (CTC) — Node interactive – MS is open sourcing Chakra, and submitting a PR to Node, mid-January +* Bert Belder (CTC) — Missed NI, was on vacation, commented on some issues +* Chris Dickinson (CTC) — Node Interactive, commenting on issues and PRs +* Shigeki Ohtsu (CTC) - Looking at new version of openssl-1.1.0 +* Steven Loomis (observer) — Node interactive, INTL meeting, went over existing issues (esp. re: TC39 standards-level happenings) +* Mikeal Rogers (observer) — Node interactive, board meeting last week, the board accepted the request for legal advice, kicked off to legal committee which will come back with a recommendation or will be handed off to outside counsel +* Jeremiah Senkpiel (CTC)- Node.js Interactive, general issues/PRs, made #io.js on freenode irc forward to #node-dev + +## Review of last meeting + +* tools: change tick processor install path [#4021](https://github.com/nodejs/node/pull/4021) +* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) +* Potential Licensing issues with npm [#3959](https://github.com/nodejs/node/issues/3959) +* Joyent Copyright still in header of many files [#3926](https://github.com/nodejs/node/issues/3926) +* doc: update irc channels to point to #node.js and #node-dev [#2743](https://github.com/nodejs/node/pull/2743) + +## Minutes + +### Discussion: OpenSSL 1.1.0 planning [#4270](https://github.com/nodejs/node/issues/4270) + +Do we want to delay v6 release for OpenSSL 1.1.0? + +James: If we stick with the current LTS cycle, the current version of OpenSSL would be supported for well past the v6 LTS. + +Alexis: Would an OpenSSL upgrade be forbidden once v6 goes LTS? + +James: + +Shigeki: API changes are large, it may be costly to upgrade before LTS. Current 1.0.2 is supported until 2019. It might be best to wait until October + +James: So, better to launch this with v7 than v6? +Jeremiah: What does it give us? + +Rod: There’s a discussion in the thread. + +Alexis: OpenSSL 1.0.2 would be supported for lifetime of v6? + +James: If the changes are large, it’s probably best not to rush it in. + +Brian: I think I agree. + +Alexis: Yes, based on the case presented here. + +James: Does anyone think we absolutely should get v1.1.0 into v6? + +`` + +James: Hearing nothing, I’m going to assume that + +Jeremiah: Do we know Fedor’s opinion on this? + +Rod: He was interested in chacha but that’s about it. +There isn’t really anything hugely compelling here. + +James: I think we’ve got general consensus for not delaying for this. We may have other reasons (V8) but not for OpenSSL v1.1.0. + +Bert: I know only the version number, delaying would require someone to make a case for it. [CD — I missed some of this due to an errant notification] + +Jeremiah: I agree with Bert + +### Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) + +Rod — left this on the agenda to provide an update. It went to the board last week. There was a bit of discussion, it went to the legal committee. They will shape the document I provided into a request for proper legal advice from a paid lawyer, somewhere — something bounded, “please give advice on these points”. the legal committee is meeting tomorrow. + +Bert: OK, cool. Why is this part of the private section of the board meeting? + +Mikeal: I can answer that. You really can’t talk about legal issues in the public section. It’s a strange constraint to be under. I’m pushing to change how we do these meetings. + +Bert: But it’s okay for the CTC to talk about? + +Mikeal: CTC is not fiduciarily bound like the board. + +### Potential Licensing issues with npm [#3959](https://github.com/nodejs/node/issues/3959) + +Rod: No updates. We have got clarification that npm is moving to the LICENSE on master branch, which is the Artistic License. + +### Joyent Copyright still in header of many files [#3926](https://github.com/nodejs/node/issues/3926) + +Rod: Same bundle as above. + +### AsyncWrap for LTS Argon [#59](https://github.com/nodejs/LTS/issues/59) + +Rod: We have AsyncWrap in v4 and v5, but undocumented, so breaking changes are okay. The question is whether or not to bring v4’s asyncwrap up to parity with v5. We landed on not documenting it in v4, but making it public in v5. + +James: I have no objections. + +Michael: Are there any performance effects? + +Trevor: No. + +Bert: I find it really strange in the state that node is in, to designate an undocumented API as LTS stable. Three people in the world, maybe, know how this API works. I’d like to have this documented before we freeze it. + +Trevor: Touching asyncwrap means touching everything. IMO it’s more about possible mitigation of issues, because you’re right, it’s totally undocumented, hidden behind process.bindings, by keeping parity, it offers advantages for backporting. It’s in a place where a lot of things will touch it, so not backporting it will make other backports difficult if not impossible. + +Bert: What you want is folks not touching it in an LTS release, because it’s risky, not to freeze it. + +Trevor: Once it is documented, I believe people will want to use it in v4, so at least we’ll have parity between v5 and v4. + +Rod: It’s in v4 now, it’s just not in the same state as in v5; the risk is that we publicize it, folks try to use it on v4, and it breaks unexpectedly. + +Trevor: There are a few places where improper use will trigger an abort. I don’t like the idea that exposing something to JS that can cause abrupt core dumps. + +James: I’d prefer not to document it in v4, + +Chris: I don’t think not documenting it in v4 will keep folks from using it once the docs hit v5. + +[minutes not captured beyond this point] + +### Discuss possibility of adjusting LTS schedule for better alignment with V8 schedule [#62](https://github.com/nodejs/LTS/issues/62) + +## Next Meeting + +December 23rd, 2015 diff --git a/meetings/2016-01-06.md b/meetings/2016-01-06.md new file mode 100644 index 0000000..53b0470 --- /dev/null +++ b/meetings/2016-01-06.md @@ -0,0 +1,216 @@ +# Node Foundation CTC Meeting 2016-01-06 + +## Links + +* **Audio Recording**: https://soundcloud.com/node-foundation/ctc-meeting-2016-01-06 +* **GitHub Issue**: https://github.com/nodejs/node/issues/4553 +* **Minutes Google Doc**: +* _Previous Minutes Google Doc: _ + +## Present + +* James Snell (CTC) +* Trevor Norris (CTC) +* Colin Ihrig (CTC) +* Brian White (CTC) +* Michael Dawson (observer) +* Alexis Campailla (CTC) +* Bert Belder (CTC) +* Chris Dickinson (CTC) +* Shigeki Ohtsu (CTC) +* Steven Loomis (observer) +* Mikeal Rogers (observer) +* Jeremiah Senkpiel (CTC) +* Rod Vagg (CTC) +* Ben Noordhuis (CTC) + +## Agenda + +Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +### nodejs/node + +* Nominating new Release team members [#4319](https://github.com/nodejs/node/issues/4319) +* repl: Reverses order of .node_repl_history [#4313](https://github.com/nodejs/node/pull/4313) +* doc: add Docs working group [#4244](https://github.com/nodejs/node/pull/4244) +* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) +* Potential Licensing issues with npm [#3959](https://github.com/nodejs/node/issues/3959) +* Joyent Copyright still in header of many files [#3926](https://github.com/nodejs/node/issues/3926) +* gripe: deprecating fs.exists/existsSync [#1592](https://github.com/nodejs/node/issues/1592) + + +## Standup + +* James Snell (CTC): Docs work, refactoring some docs, about halfway through currently. Working on landing some PRs, 4.2.4 release came out before xmas, 4.2.5 next week with Myles +* Trevor Norris (CTC): Working with Fedor to make callbacks reentrant. +* Colin Ihrig (CTC): Opened a PR for the releases doc page, reviewing issues and PRs, working on a PR to libuv +* Brian White (CTC): JS DNS resolver PR updated against master, perf compared to existing impl isn’t very good (yet?), other than that: fixed some flaky tests +* Michael Dawson (observer):Benchmarking infrastructure to generate charts, meeting this week to discuss proposed approach. Chasing down last dependency updates for AIX, adding zLinux machine. +* Alexis Campailla (CTC): Prototyping module building service +* Bert Belder (CTC): Nothing interesting +* Chris Dickinson (CTC): Poking at AsyncWrap +* Shigeki Ohtsu (CTC): Reviewing james doc improvements and small fix for tool. +* Steven Loomis (observer): Some issue review. +* Mikeal Rogers (observer): Foundation strategy for 2016, legal stuff; individual member elections are coming up. +* Jeremiah Senkpiel (CTC): Working on the v5.4.0 release at the time of the meeting. Nothing else interesting. (vacation!) +* Rod Vagg (CTC): Download metrics, analyzing that; put out infographics regarding DL numbers, end of year v4 became the most popular downloaded version, taking over from v0.10, which had been very persistent in its popularity. v5 took over 2nd place from v0.12. Reworking readme in the build repo to mention infra providers. +* Ben Noordhuis (CTC): Gloriously nothing. + +## Review of last meeting + +* Discussion: OpenSSL 1.1.0 planning [#4270](https://github.com/nodejs/node/issues/4270) +* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) +* Potential Licensing issues with npm [#3959](https://github.com/nodejs/node/issues/3959) +* Joyent Copyright still in header of many files [#3926](https://github.com/nodejs/node/issues/3926) +* AsyncWrap for LTS Argon [#59](https://github.com/nodejs/LTS/issues/59) +* Discuss possibility of adjusting LTS schedule for better alignment with V8 schedule [#62](https://github.com/nodejs/LTS/issues/62) + +## Minutes + +### Nominating new Release team members [#4319](https://github.com/nodejs/node/issues/4319) + +Rod: Ratification is desired here? +James: Any objections to adding Myles and Evan to the release team? + +`[crickets]` + +James: No objections. Who wants to take the lead on adding them? +Jeremiah: I can do that. + +* repl: Reverses order of .node_repl_history [#4313](https://github.com/nodejs/node/pull/4313) + +_Discussion in minutes doc prior to meeting discussion:_ +> CD: I won’t be able to note this one, so someone should take over for this issue. +> RV: CD - do you have an opinion to offer here? +> CD — yep! mostly: it’s a breaking change that doesn’t seem to be worth breaking things for. +> RV: thanks! + +Rod: do we want to + +Ben: seems like a pointless change, not very compelling, -1 + +Trevor: how’s it going to work when jumping between versions? my history will be all over the place. + +James: haven’t review, is this fixing an actual bug? + +Jeremiah: no, it’s just changing the order that it’s saved. + +Ben: anyone on the call in favour of making the change? + +James: Unless new information is presented, we’re leaning towards not accepting the change. + +### doc: add Docs working group [#4244](https://github.com/nodejs/node/pull/4244) + +Chris: last month, @bengl opened a PR to add the doc working group, lots of conversation has been had. Tried to pull out docs from core, came against some difficulties with finding a space to work on them and commiting them back, also wanted to have a better editorial review process so made a new repo and this also has problems because the website repo hosts some docs so docs are spanned across multiple issues. + +Ben: what’s the problem with following the contributing rules/guidelines on the node repo? + +Chris: mainly about relaxing the requirements for commit-bit, having documentation authors able to land PRs, and only docs PRs. + +Mikeal: there are several doc writers who have commit-bits, we’re talking about trying to do the clean-up prior to landing on the node repo by doing it in the docs repo first. Is there still a problem with needing commit-bit for docs people? A lot of them are collaborators already. + +Chris: I think we’re fine + +James: current process has been working well enough, this is just about giving the WG responsibility for the docs directory in the main repo + +Mikeal: sounds like the WG wants to be a holistic group working on docs across the project, not just the docs dir in the node repo? + +Chris: yes + +Mikeal: one problem I have with chartering the group at this stage then is: is the membership representative of all of these efforts? + +Chris: is the parallel effort you’re talking about in the website group? + +Mikeal: yes, and the website group is the most liberal about adding contributors so it’s not very organized + +Chris: last touch-point with the website WG was at the collab summit and they are aware of the docs WF + +Mikeal: in-person meeting not very representative of actual activity, prefer to look at who is actually contributing and pull them into the effort + +Chris: cool, will circle back and look at the two repos and pull in more individuals, concern is about doing lots of work without any guarantee of getting ratified + +Mikeal: we can’t give any guarantees without seeing things + +Chris: big amounts of work re pulling out docs into topic-tocs and tutorials + +Mikeal: but that’s already going on in the website repo, there’s tutorials that are being iterated on so why can’t we just continue that? + +Chris: core docs and tutorials etc. should live in the same place + +Mikeal: still not sure why this single issue is a blocker and how being ratified changes anything + +.. discussion .. + +Mikeal: if you wanted all of the tutorials etc. to live in core then that could just be a PR, if you want the tutorials to be moved out of the website then you’d need to be chartered and have this accepted by the website group + +Chris: problem with building momentum is that the scope of responsibility lives between two groups + +Mikeal: but there’s a ton of momentum going on in the two main places already, moving everything into a separate repo is a separate issue. + +James: need to move on, propose that we continue the conversation there + +Trevor: is there a dot-point list of what this list wants to achieve? + +Chris to update with a link to what this is + +Bert: sounds like this is not about whether this WG should exist but there is a technical blocker that we should focus on. + +James: moving discussion to github, will come back if necessary + +### Legal update + +* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) +* Potential Licensing issues with npm [#3959](https://github.com/nodejs/node/issues/3959) +* Joyent Copyright still in header of many files [#3926](https://github.com/nodejs/node/issues/3926) + +Rod: Legal committee had a meeting this week, didn’t quite get through all of it. Not resolved yet but looking like a recommendation to put a simplified license block at the top of each source file. Those were removed in io.js but DCO process discusses license in each source file. Copyright is still Joyent and that was not assigned when things were moved so we need to resolve that. + +(James: Note: we should add that to linting) + +Mikeal: Leaving Joyent in the copyright doesn’t assign new rights but may need to seek their permission to remove. Nor do we need Joyent to assign copyright. + +Rod: npm license issue still being looked at. The way npm licensing is being handled is still being worked out. + +Mikeal: May be moving towards SPDX approach. + +Ben: Question about Joyent boilerplate… is it possible that copyright actually belongs to other entity? + +Mikeal: The copyright is owned by the contributors and Joyent. Going forward, copyright is owned by the contributors. We won’t be assigning copyright to the foundation. + +James: I’ll *possibly* take the todo to get those updated + +Bert: What about binary files? + +Mikeal: It’s unclear. + +James: Can we change the DCO language? + +Mikeal: Modifying the DCO is an expensive process. Recommendation is to wait until the current stuff is resolved. + +### gripe: deprecating fs.exists/existsSync [#1592](https://github.com/nodejs/node/issues/1592) + +Bert: is the “deprecation” language useful here? + +Trevor: this was discussed + +Bert: “deprecation” is not really working + +Jeremiah: there has been some work here + +Bert: I’m against any form of deprecation from now on. + +James: Let’s keep `deprecate` to mean that the thing is strongly discouraged, let’s come up with a stronger term that means this thing will definitely be going away. + +Jeremiah: not sure if this discussion is relevant to the actual conversation. existSync is not something we want to keep because it’s different from everything else. Switch to accessibleSync? + +Trevor: (explains the issues with access and exists on windows vs linux) + +(more back and forth technical discussion about the nuances of determining if a file actually exists and is accessible) + +(James: Let’s have a function that simply returns ‘\_(ツ)_/’ on Windows in response to `accessibleSync()`) + +Trevor: Let’s take the conversation back to Github to see if we can get resolution. Agnostic on the resolution. + +## Next Meeting + +2016-01-13 diff --git a/meetings/2016-01-20.md b/meetings/2016-01-20.md new file mode 100644 index 0000000..ceffa50 --- /dev/null +++ b/meetings/2016-01-20.md @@ -0,0 +1,337 @@ +# Node Foundation CTC Meeting 2016-01-20 + +## Links + +* **Audio Recording**: https://soundcloud.com/node-foundation/ctc-meeting-2016-01-20 +* **GitHub Issue**: https://github.com/nodejs/node/issues/4780 +* **Minutes Google Doc**: +* _Previous Minutes Google Doc: _ + +## Present + +* James Snell (CTC) +* Trevor Norris (CTC) +* Colin Ihrig (CTC) +* Brian White (CTC) +* Alexis Campailla (CTC) +* Bert Belder (CTC) +* Chris Dickinson (CTC) +* Shigeki Ohtsu (CTC) +* Steven Loomis (observer) +* Mikeal Rogers (observer) +* Jeremiah Senkpiel (CTC) +* Rod Vagg (CTC) +* Ben Noordhuis (CTC) +* Domenic Denicola (observer) +* Nikita Skovoroda (observer) +* Ali Sheikh (observer) +* Evan Lucas (observer) + +## Agenda + +Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +### nodejs/node + +* Enable Node.js to run with Microsoft's ChakraCore engine [#4765](https://github.com/nodejs/node/pull/4765) +* CTC Membership Nominations [#4750](https://github.com/nodejs/node/issues/4750) +* buffer: add Buffer.from(), Buffer.zalloc() and Buffer.alloc(), soft-deprecate Buffer(num) [#4682](https://github.com/nodejs/node/pull/4682) +* Buffer(number) is unsafe [#4660](https://github.com/nodejs/node/issues/4660) +* util: deprecate `util._extend` [#4593](https://github.com/nodejs/node/pull/4593) +* ArrayBuffer.isView() and buffer.buffer property [#4420](https://github.com/nodejs/node/issues/4420) +* doc: add Docs working group [#4244](https://github.com/nodejs/node/pull/4244) +* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) +* fs: optimize realpath using uv_fs_realpath() [#3594](https://github.com/nodejs/node/pull/3594) + +## Standup + +* James Snell (CTC): Working on the Buffer issue, work on HTTP module, reviewing issues and PRs, attempting to help on 4.2.5, +* Trevor Norris (CTC): AsyncWrap related things +* Colin Ihrig (CTC): Reviewing issues and PRs. Reverted a commit +* Brian White (CTC): Not much, commenting on PRs and issues. +* Alexis Campailla (CTC): Fixing Windows issues on libuv and npm +* Bert Belder (CTC): _[CD - missed what you were looking into due to cross talk]_ +* Mikeal Rogers (observer): Various projects coming into the Foundation +* Jeremiah Senkpiel (CTC): Onboarding new release team members, Working on Timers Refactor more, trying to make sure Chakra and Buffer discussions remain productive +* Rod Vagg (CTC): Working with new contributors, lots of meetings +* Chris Dickinson (CTC): Docs WG stuff +* Shigeki Ohtsu (CTC): +* Steven Loomis (observer): +* Ben Noordhuis (CTC): Been sick, still catching up. +* Rich Trott (observer): Making tests more reliable, spinning up Testing WG +* Nikita Skovoroda “Chalker” (observer): mostly buffer, also the api usage greps are now sorted based on downloads count +* Ali Sheikh (observer): sampling heap profiler in V8 +* Domenic (observer): modules and zones +* Evan Lucas (observer): Working on getting v5.5.0 Release out and looking into v8 extras for some of the builtins. + +## Review of last meeting + +* Nominating new Release team members [#4319](https://github.com/nodejs/node/issues/4319) +* repl: Reverses order of .node_repl_history [#4313](https://github.com/nodejs/node/pull/4313) +* doc: add Docs working group [#4244](https://github.com/nodejs/node/pull/4244) +* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) +* Potential Licensing issues with npm [#3959](https://github.com/nodejs/node/issues/3959) +* Joyent Copyright still in header of many files [#3926](https://github.com/nodejs/node/issues/3926) +* gripe: deprecating fs.exists/existsSync [#1592](https://github.com/nodejs/node/issues/1592) + +## Minutes + +### Enable Node.js to run with Microsoft's ChakraCore engine [#4765](https://github.com/nodejs/node/pull/4765) + +Put on agenda by Alexis + +Alexis: MS submitted a PR for supporting Chakracore, change in node is fairly small — the shim is in the deps folder. A few CTC members have expressed interest in landing. I was wondering if anyone had opinions about how to proceed with this? + +Domenic: I’m curious about what level of support is implied. Landing it reduces the requirement of maintaining a separate fork, but + +Domenic: What’s the CTC’s goal in merging it in? + +Alexis: Adds Windows IoT. + +Domenic: but it doesn’t, because we’re not supporting it. + +Alexis: I still can build it myself. + +James: As for “why would we land it” — if this is something we think we will eventually support, landing it sends a clear signal that this is the direction we are heading. Landing it now lets the community start contributing to it, and to figure out how + +Trevor: If it was landed, we would not be providing official builds on the website. + +Jeremiah: Maybe Canary builds? + +Mikeal: Microsoft is already providing builds of this. By bringing this into the mainline, the changes get reviewed by the Core team. Its a matter of are those builds off of Node core mainline, or + +Jeremiah: Have we decided we want to this? + +Rod: We’re making a lot of assumptions. + +Trevor: Could we start an issue and list concerns? + +Domenic: Would it be a good idea to restrict to collaborators? + +Jeremiah: There’s not enough outside noise. + +Trevor: Well, the PR has garnered over 100 comments in 24 hours. + +Jeremiah: But it’s not spam. + +Mikeal: What is the title of that issue? + +Domenic: “What is the CTC’s decision on whether to merge the ChakraCore PR?” + +Trevor: or, “Things that prevent it from landing” — if we would hold back a V8 version due to incompability with the shim. James mentioned some concerns as well. + +Jeremiah: How are we going to support a shimmed VM — not officially, but for ourselves in the codebase, when we’re still using a V8 api and exposing that. + +Rod: that’s just one of the questions. + +Mikeal: No one is ever going to say “let’s support chakra” until it’s been in the codebase for a while, and has seen the MS folks show up and support it. + +Rod: We still need to get everyone on board that we want to head in that direction. I don’t think it’s fair to say “get it in the codebase and we’ll sort it out”. I see a lot of assumptions in the thread, and we need to air those assumptions and discuss them + +Mikeal: Is the discussion, “do we want to move in a VM agnostic direction?” Can we scope this? + +Domenic: My worry is: I don’t think the CTC might want to imply full VM agnosticity — they might not want to accept a spidermonkey PR? Maybe making it smaller would makemaek it easier. + +Bert: I agree with Rod that we haven’t actually had the discussion. I’ve always thought it was cool, and pushed for it, but I think _[CD ...]_ +What’s frustrating is that someone has done all the work to land a VM, but we kind of expect it to be “more than perfect” before we land it. I would suggest landing it first but not including it as a default, so we can do comparisons. + +Trevor: don’t feel too bad about this — they had to do this to support IoT. +Bert: I don’t feel bad; are we going to build a higher and higher wall until + +Rod: the problem is that we’re not on the same page, and we need to get on the same page. I’m not hearing anyone say outright that they don’t want VM agnostic. But we’re all saying different things. + +James: I agree. I don’t think there should be any rush in getting the PR landed. We can do some of that review process and take our time over the next few weeks to figure out if this is what we want to do. I don’t think anyone is saying “land it now!” We can take our time. + +Rod: My suggestion is to move back to the issue and let it evolve, and suss out the main philosophical issues from there. There’s so many things to talk about in that thread, and everyone’s g +ot a different take. We’ve got to summarize, and take our time. + +### CTC Membership Nominations [#4750](https://github.com/nodejs/node/issues/4750) + +Rod: A vote will be held in a few weeks time. In the meantime we’ll be in observer mode for these additional people. Not much to discuss here other than, “welcome!” + +### buffer: add Buffer.from(), Buffer.zalloc() and Buffer.alloc(), soft-deprecate Buffer(num) [#4682](https://github.com/nodejs/node/pull/4682) +### Buffer(number) is unsafe [#4660](https://github.com/nodejs/node/issues/4660) + +Rod: want to take it away, James? + +James: Sure everyone’s familiar with the issue up to this point. `Buffer` constructor (`Buffer(num)` or `Buffer(value)` with overloaded). Some portion of the community saying that needs changed, some real world examples of security flaws in the wild, community consensus seems to be that the API should be cleaned up — introducing new factory methods, + +Trevor: Careful saying “community consensus” + +James: Yeah — yes, the discussion seems to lead to where 4682 is now, which has been created as an EPS issue as well (https://github.com/nodejs/node-eps/pull/4). The basic idea is to introduce `Buffer.{from,alloc,allocUnsafe}()`. `allocUnsafe()` would be our current behavior for `Buffer(num)`, alloc would be zero-filled, `.from` takes the place of `Buffer(value)`. Deprecation of constructor would be docs-only, with _possibly_ a warning printed, similar to the memory leak warning on event emitter listeners. The documentation updates go along with that. That’s the overview of the discussion. _[CD phew!]_ + +Bert: What is the argument for not zeroing out buffers, exactly? why do we want to keep supporting that behavior? + +James: comes down to perf + +Trevor: That’s it. You don’t always need to zero fill. + +Domenic: I tried to read through the threads, last I saw there were no benchmarks that were completely fair. `calloc` vs. `memset`, etc. Have there been updated benchmarks? + +Trevor: if the allocation is small enough that it can use the pool, it’s not going to have perf degradation when it becomes larger. + +Domenic: My understanding with larger values is that with calloc makes it free. + +Trevor: No — over 1-4kb. + +Domenic: I don’t know what size “large” is supposed to be for calloc. + +Trevor: I’ve tried for 1mb; perf penalty is 2-3x slower, depending on size. From a dozen to a couple hundred microseconds. + +Domenic: That kind of argues to me for “safe by default.” + +Trevor: I can read in 100’s and 100’s of JSON files all of which are large, I can use fs.read with a buffer, so you have to allocate a buffer, if I have to zerofill it when I’m just going to fill it anyway, that’s just wasted cycle. + +Bert: I think most of the time that will not be the bottleneck. We might have an internal api… + +Trevor: No — the perf penalty on that is so big. This is why I initially got rid of the pooling after my first rewrite. + +Bert: optimization doesn’t have to be done right away. If you’re allocating large buffers, you’re usually mmaping it, so you don’t have to zero fill. + +Ben: But the OS is zeroing it out. + +Bert: So we don’t have to. + +Ben: There’s still CPU time being used there — it’s not free. + +James: The PR has three methods: _[CD — missed the first part]_ `alloc` will do `calloc` under the covers. If a 2nd param is passed, it will do `allocUnsafe` and fill with the string. We can compare all of these using the PR. The current implementation alloc can be 30-60% slower than `allocUnsafe`. + +Ben: We can farm out allocations to another thread, the other thread might need to overalloc a little just to have a bit in reserve. + +Trevor: At minimum that would work for the buffer pool, which is a set size anyway. + +Ben: Is anyone volunteering to write that code? + +James: I already have my hands in there. I need to look into the native buffer constructor anyway. I’ll bring it back to the discussion when I get there. + +Bert: that sounds great. I’m very happy that some experimentation and benchmarking is going on. I’m much in favor of a simple api that is safe by default. Adding a bunch of stuff — like the deprecation in the docs — we are doing too much to deal with not a very complicated issue. + +Mikeal: If you look at all of the exploits, just zero filling doesn’t solve them — they’re still a DoS vector, but no longer a disclosure. WE need the from and alloc APIs to avoid these + +Domenic: that’s a good point. I think adding more explicit APIs would help. + +James: Thank you for pointing that out — it’s an API usability issue. If we decide to zero fill by default this becomes much easier to figure out and we don’t have as much surface area to expand. There is an LTS concern with that — if we switch the default then we run into an issue where we open up a security problem, where modules assume buffer zero fills by default when it doesn’t on the current node version. I’m fine with zero-fill by default. + +Domenic: Real world apps don’t run into perf problems with this quite so often. + +Rod: What do we need to do to move forward? + +James: Ideas on speeding up initialization. Comment on the thread and we’ll go from there. + +### util: deprecate `util._extend` [#4593](https://github.com/nodejs/node/pull/4593) + +Rod: A bunch of +1’s and -1’s. + +Jeremiah: `util._extend` was added Object.assign wasn’t a thing back when we needed it, but since it was publicly exposed, all kinds of folks have used this thing and it’s in wide use. We’re discussing what we want to do with this now that Object.assign is a thing — phase out it’s use? + +Trevor: Is object.assign able to be swapped in? + +Domenic: 95% sure that is the case. + +Trevor: Could we deprecate `_extends` and change it to do Object.assign for the user. + +Domenic: If you overrode object.keys it would give different results. + +Jeremiah: `_extend` is not documented anyway, so for folks to move off of it we’d have to add docs for it or add a deprecation warning + +Rod: my concern: It’s in wide use, it’s undocumented — it just seems like a purist thing to me. “Stop using core stuff!” Apparently Object.assign is a bit slower than extend for our use in core, anyway. I just don’t see any justification for this. + +Domenic: I tend to agree. On the web we’ve got all of this stuff “webkitMatchesSelector” – better to just document it. + +Trevor: I guess what I’m getting at is that there are philosophical issues in trying to + +Document deprecation, but don’t warn on use. + +Domenic is writing a list of minor differences: https://github.com/nodejs/node/pull/4593#issuecomment-173357276 + +### ArrayBuffer.isView() and buffer.buffer property [#4420](https://github.com/nodejs/node/issues/4420) + +Trevor: now that buffer inherits from uint8array, there are undocumented methods on it. If we document that buffer extends from uint8array, then we are supporting those APIs. + +Domenic: I think it’s confusing. Either the TypedArray methods are supported or they aren’t — null them out if they’re not. + +Jeremiah: Probably nulling these things out is a good idea. + +James: in the docs we tell folks that it is a Uint8Array. + +Trevor: Documenting sounds great to me — I can get on that if everyone agrees. + +### doc: add Docs working group [#4244](https://github.com/nodejs/node/pull/4244) + +Chris: current state: call for new members (GitHub, Twitter), got significant reach, several people raising hands. Worked to define what membership means in the governance doc. Onboarding people that raised their hands. Had a second meeting for the group today. Everyone happy to work within the node repo, transition period with guides in the website repo before we get them building in the node repo. Don’t want to block core work so happy to do post-review of docs instead of holding up merges. Have a slack for collaboration now too. + +Rod: what would the post-review process look like? Similar to what we have now with the addition of review for style etc. from docs group? + +Chris: Yes, normal process, lgtm from collaborators, etc. Do a weekly review of the changes in the docs directory and do updates for that. Use slack for this by having a GitHub integration. + +Rod: Happy with progress? + +Chris: yes, going well. Building a Roadmap now for what’s going to be done. Need to telegraph what’s going to be done before it’s done. + +Jeremiah: nobody has worked on the doctool for years, is that on the roadmap? + +Chris: Plan is to build something new alongside it. + +Chris: What else needs to be done to move forward with ratification? + +Rod: Sounds like the boxes have been ticked so probably best to move back to the PR-to-core process and bring it for a vote at this meeting. + +### Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) + +Rod: No progress on that. There’s supposed be another meeting, maybe next week — no material update. I’ll keep it on the agenda to make sure we’re updated with the progress. + +### fs: optimize realpath using uv_fs_realpath() [#3594](https://github.com/nodejs/node/pull/3594) + +Trevor: There’s now realpath in libuv, making the syscall is much faster than going through the JS logic we now have. Using the cache reduces the number of lstat calls — the question is: can we work towards changing the current realpath impl to call realpath in libuv more frequently as our investigation shows is useful — since it’s faster than doing the JS logic, even with the cache. + +Jeremiah: Were there concerns about changing behavior? + +Trevor: If you give it a bad cache it would no longer fail. Some of those issues were nonissues — there’s another one about symlinks. Little edge cases that we wouldn’t consider a problem. + +Jeremiah: If we use realpath(2) that would affect the module resolution? + +Bert: Module also goes through realpath. Hopefully it doesn’t change semantics if impl changes. If the semantics stay the same, it shouldn’t be an issue. Trevor, I’ll give you an issue on why it is the way it is. On OSX, realpath could trigger a buffer overflow, there was no workaround but to write your own. On windows, it used to not exist. We used readlink on all platforms to build our realpath. + +Trevor: To clarify: we make a libuv call, not a syscall + +Bert: Libuv would need to implement this logic — maybe Ben knows? + +Ben: The issue where you could not safely allocate a buffer for the call to store its result in? That used to be an issue with OSX until 10.7 I believe, but we don’t support that anymore, so should not be an issue anymore + +Bert: If we drop WinXP support, it becomes very easy to support + +Trevor: I think we have + +Bert: I’m pretty sure it does not — [cd: might need filled in] + +Trevor: Going to test more, if the results support what you said, are you OK with using the native implementation? This boiled down to throwing away the second optional argument of the cache. + +Bert: The cache has other issues — it can be inconsistent with what’s on disk, for example + +Trevor: We’ll test it and post results. Thank you. + +Bert: cool. + +Rod: do we need to open an issue to officially drop support WinXP? + +Alexis: Changing to prevent install? + +Bert: Sooner rather than later, I think. It’d have to be a major version, and libuv would have to bump to v2 before we could drop the platform. + +Jeremiah: I don’t think that’s an issue on our end. + +Bert: It is — + +Rod: Alexis, are you in on that discussion? + +Alexis: it was a constraint of node, I thought. Everybody agreed that we would prevent node startup on winxp. + +Rod: Back to GitHub! + +### ES Module EP [nodejs/node-eps#3](https://github.com/nodejs/node-eps/pull/3) + +Trevor: One quick thing: bmeck has been working on a EP for ES2015 module loading, figuring out how it could work in node alongside commonJS — originally it was going to be [a?]synchronous. He posted a proposed API for V8, they agreed to implement it, but they want assurances that the CTC agrees on that API. What I want to say: everybody go read the module spec and +1 it. To say “Yes, if V8 adds this API, we will use it to implement ES2015 modules and the Loader spec, too.” Any questions on that? + +## Next Meeting + +2016-01-27 diff --git a/meetings/2016-01-27.md b/meetings/2016-01-27.md new file mode 100644 index 0000000..3e185c9 --- /dev/null +++ b/meetings/2016-01-27.md @@ -0,0 +1,295 @@ +# Node Foundation CTC Meeting 2016-01-27 + +## Links + +* **Audio Recording**: https://soundcloud.com/node-foundation/ctc-meeting-2016-01-27 +* **GitHub Issue**: https://github.com/nodejs/node/issues/4901 +* **Minutes Google Doc**: +* _Previous Minutes Google Doc: _ + +## Present + +* James Snell (CTC) +* Trevor Norris (CTC) +* Colin Ihrig (CTC) +* Brian White (CTC) +* Alexis Campailla (CTC) +* Bert Belder (CTC) (absent) +* Chris Dickinson (CTC) +* Shigeki Ohtsu (CTC) (absent) +* Steven Loomis (observer) (absent) +* Mikeal Rogers (observer) +* Fedor Indutny (CTC) +* Jeremiah Senkpiel (CTC) +* Rod Vagg (CTC) +* Ben Noordhuis (CTC) +* Domenic Denicola (observer) (absent) +* Nikita Skovoroda (observer) +* Ali Sheikh (observer) (absent) +* Evan Lucas (observer) +* Rich Trott (observer) +* Michael Dawson (observer) + + +## Agenda + +Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +* Enable Node.js to run with Microsoft's ChakraCore engine [#4765](https://github.com/nodejs/node/pull/4765) +* CTC Membership Nominations [#4750](https://github.com/nodejs/node/issues/4750) +* buffer: add Buffer.from(), Buffer.alloc() and Buffer.allocUnsafe(), soft-deprecate Buffer(num) [#4682](https://github.com/nodejs/node/pull/4682) +* Buffer(number) is unsafe [#4660](https://github.com/nodejs/node/issues/4660) +* doc: add Docs working group [#4244](https://github.com/nodejs/node/pull/4244) +* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) +* Drop Windows XP (and Vista) support in 6.0 [#3804](https://github.com/nodejs/node/issues/3804) + +## Standup + +* James Snell (CTC) — Buffer API change proposal, PR review, error handling summit yesterday, community related issues +* Trevor Norris (CTC) — Writing a patch for Buffer#fill, so it can accept an encoding and a buffer; making MakeCallback reentrant; have a fix but not sure how it’ll affect 3p debugger modules; want to be thorough because this should extend back to v4 +* Colin Ihrig (CTC) — Reviewing issues/PRs, fixing bugs; PR landed in libuv for looking up tmpdir, PR into child process +* Brian White (CTC) — Reviewing/commenting on PRs and issues, working on JS optimizations inside core modules. +* Alexis Campailla (CTC) — Issues/PRs, some work in the testing repo, some work in CI, visual C++ build tools for making modules, investigated a couple issues in libuv +* Chris Dickinson (CTC) — docs WG organization +* Mikeal Rogers (observer) — New education initiatives coming up from Foundation board, legal, working on size & scope of TSC stuff and the incubator +* Jeremiah Senkpiel (CTC) — Administrative and TSC stuff; moderating large issues [CD — thank you!] +* Rod Vagg (CTC) — (Possibly catching up on sleep) +* Ben Noordhuis (CTC) — Reviewing libuv+node PRs, reply to issues, 2 months ahead are busy +* Nikita Skovoroda (observer) — some comments/reviews, nothing interesting. Npm code search update. [JS - Thanks for doing the npm search things!] +* Evan Lucas (observer) — Minor dns/net cleanups, Responding to issues/PRs +* Rich Trott (observer) — Tests, spinning up Testing WG, removing redeclaration of vars from code, especially tests, thus reducing side effects and making it easier to split up tests. +* Michael Dawson (observer) — Benchmarks, results of benchmarks on the website, PPC for big endian machines, V8 testing separate from the node install +* Fedor Indutny (CTC) - Reviewing Pull Requests, fixing issues, V8 code cache API +* Seth Thompson (observer) - Google folks replied to James’ scheduling for face to face meeting for talking about swapping out VMs + +## Review of last meeting + + +* Enable Node.js to run with Microsoft's ChakraCore engine [#4765](https://github.com/nodejs/node/pull/4765) +* CTC Membership Nominations [#4750](https://github.com/nodejs/node/issues/4750) +* buffer: add Buffer.from(), Buffer.zalloc() and Buffer.alloc(), soft-deprecate Buffer(num) [#4682](https://github.com/nodejs/node/pull/4682) +* Buffer(number) is unsafe [#4660](https://github.com/nodejs/node/issues/4660) +* util: deprecate `util._extend` [#4593](https://github.com/nodejs/node/pull/4593) +* ArrayBuffer.isView() and buffer.buffer property [#4420](https://github.com/nodejs/node/issues/4420) +* doc: add Docs working group [#4244](https://github.com/nodejs/node/pull/4244) +* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) +* fs: optimize realpath using uv_fs_realpath() [#3594](https://github.com/nodejs/node/pull/3594) + + +## Minutes + +### Enable Node.js to run with Microsoft's ChakraCore engine [#4765](https://github.com/nodejs/node/pull/4765) + +Alexis: No action items on the PR itself, which was locked to collabs, since it was turning into noise. Another issue was opened (roadmap#54) by Mikeal re: whether we should be VM agnostic in the future, there’s discussion of pros and cons as well as talk of how this might happen in the future. Chakra folks are on board for the API wg group / VM agnostic API. + +Fedor: Do we have consensus yet? + +Alexis: Not yet. + +Mikeal: The vast majority agree that we should be moving toward it, + +Ben: Is it actually true? I’ve seen it go both ways. + +Mikeal: I haven’t seen objections to being VM neutral, but how we go about it — there’s no agreement at all. + +James: There’s concerns around language support between the two and how that affects us — there’s a lot of issues like that, related to the “how” we go about this, but there seems to be a consensus that this is the way we want to go. + +Mikeal: I’d like to do this before April? + +Ben: Are there collaborators that haven’t spoken up yet, on the principle that they don’t feel too strongly about it? + +Jeremiah: I’m more in line with Oglas (the guy maintaining JXCore), he’s got a lot of experience with this, and his idea was to move to its own VM. I’m not sure we could + +Trevor: You mean maintaining our own VM? + +Mikeal: I had a conversation with Mark Mayo and he thought that would be the direction we’d actually land. + +Alexis: That would require an enormous amount of resources. + +Mikeal: This PR, you say we locked it to collabs, but aren’t the folks posting it not collabs? + +Jeremiah: In the meantime we can add them to a team for this purpose. + +Alexis: I think it looks like the original PR submitter can still comment. + +Alexis: I can facilitate since I’m in contact with them daily. + +Mikeal: We should create teams for V8 and a team for Chakra, for our convenience. + +Alexis: We do have a v8 team, but I think it’s the Node experts on V8. + +Seth: I can make sure the right people from the team are on there. + +Alexis: And I can create one for the Chakra team. + +Michael: there are a few folks I’d like to add from my team, how would I do it. + +Mikeal: James can do it. + +Another question: assuming we do move this direction, should we start an issue around no longer pulling deps into the source tree? + +Michael: Being vm-neutral doesn’t mean we bring in every VM into the source tree? + +Mikeal: But we’re set up to do that right now. + +Alexis: This also affects ICU. + +Jeremiah: I don’t think this is an immediate concern. + +Fedor: Release cycle — Chakra and V8’s release cycle are not aligned, how will that affect us? + +Alexis: Chakra team has folks dedicated to working with Node’s release cycle, so we would align. + +Mikeal: If we tackle this ABI compatibility problem, we may end up revisiting the release cycle since that’s driven by these big VM breaks. + +### CTC Membership Nominations [#4750](https://github.com/nodejs/node/issues/4750) + +Jeremiah: We’re going to keep this open for a couple weeks while the nominees sit in. The vote is TBD. We don’t do this often so the process is rusty. + +### buffer: add Buffer.from(), Buffer.alloc() and Buffer.allocUnsafe(), soft-deprecate Buffer(num) [#4682](https://github.com/nodejs/node/pull/4682) + +James: Where we’re at right now: continuing to update the PR and the EPS proposal that goes along with this based on the conversation. The new APIs seem uncontroversial. Unsurprisingly the name of one method is the most controversial. Currently, it’s allocUnsafe, a few folks don’t like “Unsafe”, would prefer “Raw”. [CD - yay bikesheds!] + +Some of the feedback from Trevor was that the API should be tweaked a bit, where we can pass encoding or a buffer to `.fill`, other than that the conversation around it is dying down. We haven’t decided if we’re going to change the default `new Buffer(n)` to zero-fill — if we do make that change we have to make it all the way down to v0.10 to keep it consistent. + +Mikeal: Call it buffer.remoteDisclosure(). + +Just kidding. + +Ben: if we could make zero-fill as fast as the current impl, then we would of course pick that. + +James: Yes. + +Ben: I’ve been playing with doing init in a separate thread. Perhaps I can close the gap. + +Mikeal: The only objection is perf. + +James: Yep. The baseline impl is that zero fill uses calloc. + +Trevor: We use a pool. It’s always been possible to reach the pool from any buffer instance. Do we want to remove pooling? + +James: Current impl is that zerofill does not pool. + +Trevor: So much overhead! + +_(in document chat)_ + +_Chris: why not use WeakMap for pooling?_ + +_Ben: no weakmaps in v0.10._ + +Jeremiah: Do we have benchmarks for calloc? + +James: Once we get a little further, I’ll revisit benchmarks. + +Trevor: Can the kernel do magic where memory isn’t actually allocated when it’s done in a tight loop? [CD - I didn’t capture this completely] + +Ben: You can mmap memory, memory isn’t actually allocated + zerofilled until you touch it, but touching it causes a page fault. + +### Buffer(number) is unsafe [#4660](https://github.com/nodejs/node/issues/4660) + +Jeremiah: Looks like we covered this. + +### doc: add Docs working group [#4244](https://github.com/nodejs/node/pull/4244) + +Chris: Onboarded some folks. Completed drafting the docs roadmap proposal. Making sure we have adequate tooling to build docs to the website from the node.js core repo. + +Chris: There is a docs wg meeting next week [10AM PST] [Wednesday @ 10am Feb 3rd] + +Chris: Also working with the inclusivity WG to make a new collaborator guide. + +Ben: No loosening of commit formatting, right? + +Chris, Mikeal: nope + +Jeremiah: Has anyone read through the proposed charter? + +Mikeal: hasn’t changed recently + +Ben, James: read though it recently, lgtm + +Jeremiah: Vote? + +Mikeal: No need, no-one objects. + +Jeremiah: Ok, good to go. + +### Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) + +Mikeal: We’re nearing final documents, and we have some additions to contributing guide that come from legal. The SPDX stuff we talked about. The Foundations IP policy, we mention that we’re going to use CC-4.0 for docs. We should put this to the Docs WG about this. We should have a proper policy from the legal committee really soon. + +Chris: I will bring the CC-4.0 license to the Docs WG. + +### Drop Windows XP (and Vista) support in 6.0 [#3804](https://github.com/nodejs/node/issues/3804) + +Jeremiah: Realpath brought this back up. + +Ben: That was Rod but I can take over. The proposal was to drop vista support in the next major release, that would let us drop a lot of legacy of code. TBH, I thought we had already decided on this, so I’m surprised about this. If you’re not in favor, now would be the time to speak up. + +Trevor: Didn’t libuv drop XP? + +Ben: Nope. + +Trevor: Everything but some subset of the API works on XP? + +Alexis: I also thought this decision was already made. + +Jeremiah: It might have been in some other issue. I seem to recall. + +Alexis: Does anyone object to dropping XP? + +_[crickets]_ + +Fedor: I do! `` + +No objections. + +Alexis: Does anyone object to drop Vista support. + +Mikeal: Let’s get data from NPM. + +Ben: Info was posted on the issue, looks like there’s more XP users than Vista, but still very small percentage. + +Mikeal: Last I checked there were banks that required it, so it’s still out there. + +Trevor: They have LTS, right? + +Colin: If we were going to drop support, that we need to start messaging as soon as possible. + +Alexis: And that we’d put a check so that Node would exit on those platforms. + +Mikeal: It sounds like we’re going to cut some number of users. As long as we’re okay with that… + +Alexis: I think we’re going to support the other users better. + +Trevor: We have v4, and that will be around for [another year? CD] Maybe even V8 won’t support XP by the time v4 expires. + +Jeremiah: I think V8 already stopped supporting it. + +Alexis: I think Nikita articulated that. + +Jeremiah: Seth, if you’re still there, do you have any idea when V8 will drop XP support. + +Seth: We’ve planned that Chrome will probably drop XP support at the same time as … I have to double check. I’ll come back when I find out. + +Mikeal: We’ll drop it, and if anyone complains we’ll just say Microsoft told us to do it :) + +Alexis: I can make the change to stop on startup; in terms of messaging what needs to happen? + +Colin: We just need to get the word out. A tweet or a blogpost or something? + +Jeremiah: We should loop in marketing. + +Seth: It’s April 2016 for sure on the Chrome side. + +Jeremiah: So we have 3 months. + +Mikeal: It’d be a major? + +Jeremiah: Yep. v6. + +Alexis to PR this in. + +## Next Meeting + +2016-02-03 diff --git a/meetings/2016-02-03.md b/meetings/2016-02-03.md new file mode 100644 index 0000000..687cbe7 --- /dev/null +++ b/meetings/2016-02-03.md @@ -0,0 +1,223 @@ +# Node Foundation CTC Meeting 2016-02-03 + +## Links + +* **Audio Recording**: https://soundcloud.com/node-foundation/ctc-meeting-2016-02-03 +* **GitHub Issue**: https://github.com/nodejs/node/issues/5058 +* **Minutes Google Doc**: +* _Previous Minutes Google Doc: _ + +## Present + +* James Snell (CTC) +* Trevor Norris (CTC) +* Colin Ihrig (CTC) +* Brian White (CTC) +* Alexis Campailla (CTC) +* Bert Belder (CTC) x +* Chris Dickinson (CTC) +* Shigeki Ohtsu (CTC) +* Steven Loomis (observer) +* Mikeal Rogers (observer) +* Fedor Indutny (CTC) +* Jeremiah Senkpiel (CTC) +* Rod Vagg (CTC) +* Ben Noordhuis (CTC) +* Nikita Skovoroda (observer) +* Evan Lucas (observer) +* Rich Trott (observer) +* Michael Dawson (observer) + + +## Agenda + +Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +## Standup + +* James Snell (CTC) — Working on the security fix stuff, buffer stuff, express TLP proposal +* Trevor Norris (CTC) — Commenting, working on making AsyncWrap a public API +* Colin Ihrig (CTC) — Just reviewing PRs and issues +* Brian White (CTC) — Reviewing PRs and issues, submitting various PRs. Working on performance improvements throughout core. +* Alexis Campailla (CTC) — Reviewing issues & PRs, drop XP support PR +* Chris Dickinson (CTC) — Docs WG Roadmap ratified (!), Promises PR +* Shigeki Ohtsu (CTC) — Upgrading OpenSSL and reviewing several PRs. +* Steven R. Loomis (observer) — met w/ TC39/Ecma402 folks to move items forward. worked on full-icu (#3460 - in the agenda) packaging and also locale negotiation https://github.com/nodejs/Intl/issues/10 - recommend docs (?) + small non-core module. +* Mikeal Rogers (observer) — TSC-level stuff, contribution agreement; updates on copyright stuff for core. +* Fedor Indutny (CTC) — reviewing PRs/issues, working on landing c-ares, OpenSSL patches +* Jeremiah Senkpiel (CTC) — Not much notable, TSC things (administrative wrangling) +* Rod Vagg (CTC) — Security issue, administrative wrangling, struggling a little to keep on top of everything +* Ben Noordhuis (CTC) — Wrote some code, reviewed some code, answered questions, replied to bug reports. +* Nikita Skovoroda (observer) — Commenting, nothing significant. Minor work on the npm code search tool. +* Evan Lucas (observer) — Issue and PR review. Looking into some minor stream performance things. +* Rich Trott (observer) — Test improvements; tightening linting rules; finding/closing old/stalled issues/PRs; Testing WG second meeting later this week +* Michael Dawson (observer) — Adding AIX machine, CI jobs, Job for V8 testing in Node tree, PPC BE release machine investigation, Benchmarking infra. + +## Review of last meeting + +* Enable Node.js to run with Microsoft's ChakraCore engine [#4765](https://github.com/nodejs/node/pull/4765) + - (Skip, also in this meeting) +* CTC Membership Nominations [#4750](https://github.com/nodejs/node/issues/4750) + - (Skip, also in this meeting) +* buffer: add Buffer.from(), Buffer.alloc() and Buffer.allocUnsafe(), soft-deprecate Buffer(num) [#4682](https://github.com/nodejs/node/pull/4682) & Buffer(number) is unsafe [#4660](https://github.com/nodejs/node/issues/4660) + - (Skip, also in this meeting) +* doc: add Docs working group [#4244](https://github.com/nodejs/node/pull/4244) + - Ratified +* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) + - (Skip, also in this meeting) +* Drop Windows XP (and Vista) support in 6.0 [#3804](https://github.com/nodejs/node/issues/3804) + - Agreed to drop + +## Minutes + +### Enable Node.js to run with Microsoft's ChakraCore engine [#4765](https://github.com/nodejs/node/pull/4765) + +_(Jeremiah: This should probably be the VM neutral discussion https://github.com/nodejs/roadmap/issues/54)_ + +Jeremiah: Someone tagged the roadmap issue on this. It might be more useful to talk about the VM neutrality issue rather than the PR. + +Ben: Has anyone started reviewing the PR yet? + +Alexis: Yes, there was a first review, an update, and a follow-up. I agree that the most interesting discussion is on the roadmap issue. + +Rod: How are we going to make progress on this? Should we wait until after the VM summit that James is organizing, or is there another way? + +Alexis: We could make a high level evaluation of whether we see value in VM neutrality or not, that could make progress. + +Michael: That’s what the issue was intended for in the first place. + +Jeremiah: There’s been a suggestion that the PR should be broken up a bit, to make reviewing more reasonable. + +Mikeal: I think the question CTC needs to answer sooner rather than later: do we hold up Chakra on a resolution, land it on a branch, etc. What is a “good” solution to work from while we don’t have a “perfect solution” [cd - some paraphrasing here] + +Rod: We need the high level questions answered — the ones too hard to answer in github. + +Mikeal: We need to give the people that want to work on Chakra specifically a place to work on it, while we figure out what we want. + +Alexis: Answering whether we want VM neutrality at all could make progress. + +James: Does anyone have objections to being VM neutral, at a high level. + +Ben: Not objections as such, but I do question how valuable it is. + +Alexis: It’s a matter of value vs. cost then. If it’s free, then of course we would add it. + +Ben: Yes. + +Michael: Even if we never add another VM, making the VM bindings more stable is a net win. + +Rod: We do have to be careful assuming this is something people are actually for. + +Michael: Shipping with a different VM might be more controversial than making it _possible_ to ship with a different VM. + +Trevor: [CD interpretation: part of the difficulty is the degree to which VM is complected with node c++, perhaps we should focus instead on a low level JS api.] + +Michael: Would this let us land V8 updates easier? + +Trevor: Once we have a sanctioned API, yes. Buffers are a good example of this. + +Mikeal: There are lots of examples of folks that copy over the entire JS API — even they end up writing something of a shim layer to get native modules. This LLJS API would not be the entire story. + +[CD: Michael and Trevor discuss subsets of APIs to support.] + +Mikeal: We should have this conversation at the summit. Where do we tell folks who want to work on Chakra to work? + +Ben: It only works on Windows. + +Mikeal: We could say, we’re going to put it on a branch, and you can work with the Build WG to produce builds. There’s a lot of MS folk that want to see this work, and we stand to learn a lot from the process of how this works. + +Ben: Are we the first line support? + +Alexis: There is a team of engineers dedicated to this. + +James: We could stand up a separate repo, with its own issue tracker + PRs. + +Rod: It’s also a discussion about the size of the tree. We talking in the build WG about different ways of vendoring to address this. A separate repo sounds interest. + +Jeremiah: Would that separate repo be the shim, or a fork of Node.js? + +Rod: it would be a fork. + +Jeremiah: It’d be nice to have the build process pull in the shim and chakra and build it. + +Rod: There’s a discussion in the Build WG repo about this. There’s not an easy way to do this. + +Rod: In terms of making progress right now, a fork repo is probably the best way to go — reducing the number of + +Jeremiah: I don’t think VM neutral is the way to go, I think our own VM is the way to go. There are concerns in the thread about how we impact userland — it’s unclear how modules will have to support that between different VMs. + +Mikeal: Folks using ES6 transpile. + +[CD and Jeremiah: not always!] + +Rod: The folks who care will do the work — when I publish a module I publish it to work for me — when someone else needs it to work else where they can PR it. The big benefit I see of VM neutrality is that we become part of a competitive landscape of VMs. MS really wants to get into this game, and compete with V8. We see it in the browser ecosystem, where the competition has shifted from perf to features, and it’d be interesting to see that applied to the node ecosystem. + +Jeremiah: Time check. + +Rod: in terms of progress, does anyone object to making a separate repo for this? + +[No objections!] + +### CTC Membership Nominations [#4750](https://github.com/nodejs/node/issues/4750) + +Rod: We’ll leave this for a couple more weeks. Moving on. + +### buffer: add Buffer.from(), Buffer.alloc() and Buffer.allocUnsafe(), soft-deprecate Buffer(num) [#4682](https://github.com/nodejs/node/pull/4682) & Buffer(number) is unsafe [#4660](https://github.com/nodejs/node/issues/4660) + +James: Discussion has settled out. No new comments. Updated PR yesterday with a couple changes I discussed with Trevor. Close to being done, just a matter of cleaning up the PR a bit and making sure there are no objections. It is a semver-major. We haven’t decided if we’re going to deprecate the Buffer(n) api. + +Rod: Is it worth jumping in with naming issues — e.g., opposing the word “Unsafe” — now? + +James: Some folk really don’t like typing “unsafe”, but it is, _technically_, unsafe. + +[CD: Perhaps we should call it “allocXtreme”] + +Rod: Personally I don’t want “unsafe”, but I’ve been holding off. + +James: If you’ve been holding off on it, I don’t really care about the name too much. We can take it back to GH. + +### Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) + +Rod: Likely a two line comment at the top of all files. + +### @srl295: [path for full-icu data?](https://github.com/nodejs/node/issues/3460) - ./node_modules vs ./node/ ? (npm linkage) + +Steven: Put together a proof of concept. Core question here is: is full-icu try to use a directory such as node_modules, or is that hijacking it for improper use [cd: unsure if I captured that correctly] + +Result from Nov CTC meeting was “No objections to using node_modules”, and so I’m looking for feedback. + +Alexis: I thought the no objection was to a separate directory. + +Steven: Node module writes into some other known directory. + +Steven: The node installer or deb pkg could have a checkbox to install icu data. + +Rod: We could ship multiple installers. + +Re the package: Perhaps we should use `execPath` to determine installation location? + +Steven: Is execPath relative? + +Rod: It’s absolute. + +Steven: so that would be for global install — local install would use `node_modules/`. + +Rod: We could take a page from npm’s `.bin` and use `.lib`. I’m assuming the problem is that Node needs to look for this before it even gets to module resolution. + +Steven: Right, this has to happen before ~~V8~~ **your VM** starts up. + +Alexis: So I don’t think this belongs in `node_modules/`. + +Rod: Possibly `.node-icu`? + +Steven: Local is `node_modules/.node-icu`? + +Rod: Maybe writing up the details on GH and pulling us in? + +Steven: This is some good progress. It seems like it deals with the problem that it doesn’t overload an actual module; I’ll write up a proposal for this. Probably tomorrow. + +Rod: Any other comments for that? + +## Next Meeting + +2016-02-10 diff --git a/meetings/2016-02-10.md b/meetings/2016-02-10.md new file mode 100644 index 0000000..06bf359 --- /dev/null +++ b/meetings/2016-02-10.md @@ -0,0 +1,167 @@ +# Node Foundation CTC Meeting 2016-02-10 + +## Links + +* **Audio Recording**: https://soundcloud.com/node-foundation/ctc-meeting-2016-02-10 +* **GitHub Issue**: https://github.com/nodejs/node/issues/5176 +* **Minutes Google Doc**: +* _Previous Minutes Google Doc: _ + +## Present + +* James Snell (CTC) +* Trevor Norris (CTC) +* Colin Ihrig (CTC) +* Brian White (CTC) +* Alexis Campailla (CTC) +* Bert Belder (CTC) +* Chris Dickinson (CTC) +* Shigeki Ohtsu (CTC) +* Steven Loomis (observer) +* Mikeal Rogers (observer) +* Fedor Indutny (CTC) +* Jeremiah Senkpiel (CTC) +* Rod Vagg (CTC) +* Ben Noordhuis (CTC) +* Nikita Skovoroda (observer) +* Ali Sheikh (observer) +* Evan Lucas (observer) +* Rich Trott (observer) +* Michael Dawson (observer) + +## Agenda + +Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +* Revert "fs: deprecate fs.read's string interface" [#5163](https://github.com/nodejs/node/pull/5163) & fs: add a temporary fix for re-evaluation support [#5102](https://github.com/nodejs/node/pull/5102) +* buffer: add Buffer.from(), Buffer.alloc() and Buffer.allocUnsafe(), soft-deprecate Buffer(num) [#4682](https://github.com/nodejs/node/pull/4682) & Buffer(number) is unsafe [#4660](https://github.com/nodejs/node/issues/4660) +* CTC Membership Nominations [#4750](https://github.com/nodejs/node/issues/4750) +* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) + +## Standup + +* Brian White: Working more on improving performance in various areas of core, reviewing PRs and issues. +* Chris Dickinson: Promises PR + discussions with the error symposium group. +* Rich Trott: addressing flaky tests, enhancing linting, working to find a path to more automation in landing of PRs (although others, including Alexis, seem to have picked that ball up, thankfully) +* James Snell: Working on express stuff in, security stuff out, buffer API finished, moving forward on string externalization. +* Jeremiah Senkpiel: Hook for unhandled rejections that detects when the GC fires on a promise. That is currently blocked on V8 bug with weak callbacks + promises. +* Chris Dickinson: Promises PR + discussions with the error symposium group. +* Trevor Norris — MakeCallback reentrant fix for HTTP parser / AsyncWrap interaction. +* Michael Dawson - Working on getting AIX up in the CI. Also on running v8 tests in the Node tree. Added AIX to libuv tests. +* Steven R. Loomis - not much to add +* Nikita Skovoroda — like ususal, mostly comments and the initial version of the codesearch API on a VPS. Nothing major. +* Rod Vagg - Security stuff, catching up on issues and discussions. Legal committee meeting yesterday. + +## Review of last meeting + +* Enable Node.js to run with Microsoft's ChakraCore engine [#4765](https://github.com/nodejs/node/pull/4765) +* CTC Membership Nominations [#4750](https://github.com/nodejs/node/issues/4750) +* buffer: add Buffer.from(), Buffer.alloc() and Buffer.allocUnsafe(), soft-deprecate Buffer(num) [#4682](https://github.com/nodejs/node/pull/4682) & Buffer(number) is unsafe [#4660](https://github.com/nodejs/node/issues/4660) +* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) +* @srl295: [path for full-icu data?](https://github.com/nodejs/node/issues/3460) - ./node_modules vs ./node/ ? (npm linkage) - todo, update ticket with meeting resolution + + +## Minutes + +### Revert "fs: deprecate fs.read's string interface" [#5163](https://github.com/nodejs/node/pull/5163) & fs: add a temporary fix for re-evaluation support [#5102](https://github.com/nodejs/node/pull/5102) + +Rod: Simple deprecation warning for the particular argument usage. Pulling in the internal util module for deprecation messes up older versions of graceful-fs (and thus older versions of npm.) The question is whether to revert the PR, or to add a helper (that Nikita proposed.) I would suggest that this is urgent enough that we need to do something about it. + +Jeremiah: This is a poor reason to revert it. +James: From everything that I’ve seen, adding the warning is the least bad option. Folks seems to be against reverting. Maybe making the warning less specific to graceful-fs. + +Ben: I don’t agree. I think it’s right to point them to the newer version. + +Jeremiah: I agree (with Ben). + +Rod: Anytime you break the build, it’s an immediate candidate for reversion. It’s not permanently reverted, but it’s “let’s fix the build.” + +Jeremiah: This doesn’t actually break CI though. It breaks newer versions of npm on master. .. It might be npm in general just on the master branch. + +James: Forrest noted that pretty much any change other than reverting will have a significant effect on the npm user base. + +Jeremiah: Yeah but we’re not shipping this in a stable. + +Michael: If it breaks in master, doesn’t that prevent folks from doing other tests? + +Ben: I think the problem lies with npm here. + +Mikeal: You make that sound so easy. + +Ben: The version of npm we’re talking about is still in a PR, yes? + +Jeremiah: We don’t regularly run tests on master, so it might already be broken. I can test it right now.. + +Rod: I think Myles has been trying to run the npm tests more regularly, as part of smoke testing — and it’s broken for the smoke testing now. + +Michael: It seems like we’d want to keep things as green as possible. It seems like we’d want npm to do something. + +Rod: It’s a fact of life that we exist in an ecosystem that has these kinds of issues. My vote is to revert, and then revisit after we’ve gotten the build fixed. + +Ben: Well, yeah, I do. I think Nikita’s PR is an acceptable intermediate solution. + +Jeremiah: Likewise. The resolution is that we try to require it, if that fails, we use a deprecation helper we build in that emits a warning that something is breaking an internal module — that would fix it and seems quite reasonable. It will also help people note where stuff is going to break. + +Rod: Does someone want to help Nikita get this in? + +Ben: Didn’t you already get a couple of LGTMs? + +James: I think there’s one -1 and three LGTMs. + +Rod: We can force it if we have to. + +James: I propose: if we accept this now, let’s try to get it resolved better before v6 goes out — which gives us a deadline so it’s not pushed off indefinitely. npm gets a fix, and that’s where it happens. + +Ben: I think it’s a good idea to push npm to update their dependencies. Whether or not npm updates, I think it’s a good idea to include Nikita’s PR. + +Jeremiah: I think so too. + +Rod: Let’s take it back to GitHub. + +### buffer: add Buffer.from(), Buffer.alloc() and Buffer.allocUnsafe(), soft-deprecate Buffer(num) [#4682](https://github.com/nodejs/node/pull/4682) & Buffer(number) is unsafe [#4660](https://github.com/nodejs/node/issues/4660) + +James: There were some changes I was waiting for from Trevor w/r/t fill encoding. There was a desire to bikeshed a bit more on the name, not sure if you want to do that here. I think absent that the PR is probably in a place where we can land it. + +Rod: Sounds like we need a last call for objections, otherwise it’s going in. + +James: Yep. + +Rod: How about you do that on GitHub? + +James: OK. + +Jeremiah: Are you adding a zero-fill flag? + +James: Yes — it will switch all allocations to use calloc under the hood. The one thing this does not do is change the default behavior of `new Buffer(size)`. If we did that, it would be a breaking change going back to 0.10. + +Bert: Is the plan to deprecate it off the table? + +James: It’s a soft deprecate — docs only. + +Jeremiah: We should try to just deprecate it. The problem is that folks are running different versions against modules, and it would be bad to rely on zero-fill behavior where it doesn’t exist [CD — didn’t capture this entirely] + +James: We need to refine our deprecation strategy — and define whether something is deprecated vs. end-of-life. Will probably be returning to that next week or the week after. + +Rod: It sounds like we’ve got a way forward, here. + +Bert: It’s ugly but I won’t object. + +Rod: Noted. + +### CTC Membership Nominations [#4750](https://github.com/nodejs/node/issues/4750) + +Rod: We should start to line up a vote. + +### Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) + +Rod: There was a PR that Mikeal put in that updates the DCO from v1.0 to v1.1. If you’d like to review that, please comment on that. + +### Other business + +James noted that the express application landed today. I will be working to move that into the new organization. More of an update on tomorrow’s TSC call. + +Jeremiah notes that he will be a bit preoccupied by that for a while. + +## Next Meeting + +2016-02-17 diff --git a/meetings/2016-02-17.md b/meetings/2016-02-17.md new file mode 100644 index 0000000..25aa395 --- /dev/null +++ b/meetings/2016-02-17.md @@ -0,0 +1,240 @@ +# Node Foundation CTC Meeting 2016-02-17 + +## Links + +* **Audio Recording**: https://soundcloud.com/node-foundation/ctc-meeting-2016-02-17 +* **GitHub Issue**: https://github.com/nodejs/node/issues/5274 +* **Minutes Google Doc**: +* _Previous Minutes Google Doc: _ + +## Present + +* James Snell (CTC) +* Trevor Norris (CTC) +* Colin Ihrig (CTC) +* Brian White (CTC) +* Alexis Campailla (CTC) +* Bert Belder (CTC) +* Chris Dickinson (CTC) +* Shigeki Ohtsu (CTC) +* Steven Loomis (observer) +* Fedor Indutny (CTC) +* Rod Vagg (CTC) +* Ben Noordhuis (CTC) +* Nikita Skovoroda (observer) +* Ali Sheikh (observer) +* Evan Lucas (observer) +* Rich Trott (observer) +* Michael Dawson (observer) +* Seth Thompson (observer) +* Mikeal Rogers (observer) + +## Agenda + +Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +* Issue management: discuss caine again [#5246](https://github.com/nodejs/node/issues/5246) +* refactor src/node.js into internal files [#5103](https://github.com/nodejs/node/pull/5103) +* process: add 'warn' event [#4782](https://github.com/nodejs/node/pull/4782) +* CTC Membership Nominations [#4750](https://github.com/nodejs/node/issues/4750) +* buffer: add Buffer.from(), Buffer.alloc() and Buffer.allocUnsafe(), soft-deprecate Buffer(num) [#4682](https://github.com/nodejs/node/pull/4682) & Buffer(number) is unsafe [#4660](https://github.com/nodejs/node/issues/4660) +* Check in ICU into repo? [#3476](https://github.com/nodejs/node/issues/3476) - Steven R. Loomis - +1 on checking in <45M into repo? so Jenkins servers will never again have to download ICU +* Detect ICU data at startup? [#3460](https://github.com/nodejs/node/issues/3460) - Steven R. Loomis - +1 on ≈/node_modules/.node-icu ? + + +## Standup + +* James Snell: Working on a few PRs, the buffer change, the process.warning, looking at doc updates — backporting. Looking at other PRs, getting ready for conference. +* Trevor Norris: AsyncWrap bug on raspberry pi, getting two tcpwraps when creating a server instead of just one. +* Colin Ihrig: Review of issues tagged with child_process label and PR for adding options to process.send(). +* Brian White: fixing bugs, cleaning up code, more performance testing, reviewing PRs and issues. +* Bert: N/A +* Alexis: Mostly working on chakracore, moved the repo from ms/node, define participation guidelines; adding support in CI +* Chris Dickinson: Promises PR + WG (https://github.com/nodejs/promises). Microtask queue pluggability (https://github.com/chrisdickinson/node-1/pull/2). +* Shigeki Ohtsu: Reviewing a few PRs and issues and make my internal works. +* Steven R. Loomis: Intl packaging stuff +* Fedor Indutny: Reviewing PRs, fixing issues +* Rod: Promises, v5.x management, people & administrative stuff +* Ben: Promises PR, and ES2015 module interop, there’s a lot to take in, no fully formed opinions yet. +* Nikita Skovoroda: mostly comments and reviews, as usual. +* Ali Sheikh: Back from 2 weeks of vacation. Catching up on mail & jetlag. Progress on Sampling Heap Profiler in V8. Was involved in Error summit before vacation. +* Evan Lucas: Working on some http things (cleanup, etc.). Wrote CLI tool for submitting jenkins builds and viewing CI status. +* Rich Trott: flaky tests; updating ESLint; finding stale issues and closing, tagging, or taking other appropriate action +* Michael Dawson: Working through AIX issues, landing pr, working on setting up job/answering question on running V8 tests in Node tree, benchmarking infra/new benchmarks, discussion with Richard on post-mortem WG activity and work, trying to read issues with high traffic. +* Mikeal Rogers: Foundation stuff, DCO 1.1 patch. +* Seth Thompson: Traveling the past week or so; working on revamping profiling and metrics on our perfbots, and trying to get Node building on the chromium bots, to assist with the benchmarking WG. + +## Review of last meeting + + +* Revert "fs: deprecate fs.read's string interface" [#5163](https://github.com/nodejs/node/pull/5163) & fs: add a temporary fix for re-evaluation support [#5102](https://github.com/nodejs/node/pull/5102) +* buffer: add Buffer.from(), Buffer.alloc() and Buffer.allocUnsafe(), soft-deprecate Buffer(num) [#4682](https://github.com/nodejs/node/pull/4682) & Buffer(number) is unsafe [#4660](https://github.com/nodejs/node/issues/4660) + +## Minutes + +### Issue management: discuss caine again [#5246](https://github.com/nodejs/node/issues/5246) + +Fedor: A year ago I submitted an idea, and we tried it for a bit, to use a GH bot to help us manage issues on GH. This was to address the pace of issues. The idea was to introduce a bot that automatically assigns issues to people based on tags & user responses to questions. It didn’t take off at the time, the reason being we didn’t want to be too automatic. Chris had some issues with it. I wanted to see if we could take another look. + +Mikeal: Today GH slipped in an issue template feature. We may want to investigate that. + +Fedor: Indeed this should solve the thing for us. We can ask folks to mention some specific working groups. + +Bert: I also had objections to the first version of caine, I felt like it would only add noise — it would still ask questions even if the issues had been answered. I would suggest we start with the template then look at what caine could add to it. Maybe autotagging? + +Mikeal: We have a lot of folks tagging, but we don’t have a good way for limiting email notifications. Maybe autoassign tags to users? + +Bert: I am not opposed to this. + +Mikeal: Maybe it should never comment. + +Fedor: I kind of disagree with this. My workflow: I was actively using GH teams to filter emails. If the bot would be able to assign the tags — and cc teams in a single comment. + +Chris: I’d second that. + +Rod: I’d advise starting light; it may get pushback if it comments too much. + +Ben: What exactly would you change? + +Fedor: Autotagging based on responses in template. We’ll ask folks to name the part of core in the template, and add a mention of the relevant GH team so that they get notifications. + +Mikeal: If someone wanted to take on an interesting side project, feeding issues + tags into ML would be pretty cool. + +Bert: I think that’s a really interesting idea actually. + +Mikeal: Maybe some IBM folks that have access to Watson could do this? + +Bert: Maybe we could give interested folks an account? + +James: [CD: Paraphrasing: It seems possible.] If anyone’s interested in this, send me a note offline. + +### refactor src/node.js into internal files [#5103](https://github.com/nodejs/node/pull/5103) + +Jeremiah tagged this one. Tagged because it’s heavy-handed into splitting `src/node.js` into sub-files in the internal directory. + +James: It is a big change, but it seems to be one that’s fairly safe. I didn’t notice any things that would obviously break. Given the code that it does touch, it’s worth being conservative and careful pulling it in. I’m +1 on it, but I think we need to be careful. + +Chris: Naming issues. + +Ben: Memory overhead. Script objects have a moderately sized footprint, so that’s a thing to keep in mind. + +Rod: I think we could name the files with `bootstrap-`. With regards to any objections to doing this… There’s the usual fear re: size of changes, memory, breaking people’s workflows. Is there anything else to discuss here? + +Michael: Suggest running the footprint benchmark to get a feel. + +Ben: Will post on GH. + +[CD: Moved to GH] + +### process: add 'warn' event [#4782](https://github.com/nodejs/node/pull/4782) + +James: Came from how we do warnings currently, which is to drop it out into console.error now. This restructures it a bit to put it into a warning event on the process object, allows users to listen to those warnings. Mainly looking for review. Existing command line arguments are still supported, but messages are changed a bit. Adds ability for us to add warning for security purposes or bad practices. Process.emit ‘warning’ allows users to emit their own warnings. It came up via the buffer changes — where we could issue a warning for users using the new Buffer constructor in an unsafe way. Just looking for review, nothing too controversial. + +Trevor: The buffer constructor needs to have to have the same signature as Uint8Array for subclassing purposes. + +Michael: This captures all output to stderr from core? + +James: No, just the warnings, like the EE maxlisteners warning. The default behavior is to print it to console, but it may be overridden by user handlers. Folks from electron have said that this is something that they like. + +Rod: Any concerns or objections raised in GH? + +James: Not thus far — tty check raised by Jeremiah + +Trevor: Does it sent the output to stderr/stdout only or could one provide a file descriptor? Looks like you're building a messaging system... + +James: Default behavior is to print to stderr, but you can turn off this behavior by installing your own listener. + +Chris: Are we sure no one’s using process.emit(‘warning’)? + +James: Did a search and came up with no results. + +Chris: Excellent. + +Rod: It’s more than adding an event, it’s worth taking a look. + +James: [CD: my internet is flaking out] Mostly trying to get it on folks’ radar. If folks can take a look and provide their feedback. + +Rod: FWIW I think this is a great change. Unifies and adds some nice functionality around these warnings. + +### CTC Membership Nominations [#4750](https://github.com/nodejs/node/issues/4750) + +Rod: Any objections to putting this to a vote next week? + +[crickets] + +### buffer: add Buffer.from(), Buffer.alloc() and Buffer.allocUnsafe(), soft-deprecate Buffer(num) [#4682](https://github.com/nodejs/node/pull/4682) & Buffer(number) is unsafe [#4660](https://github.com/nodejs/node/issues/4660) + +James: added ability to specify byte offset and length, both to `.from` and [CD: missed this] + +James: No significant objections, except to allocUnsafe which folks really don’t like the naming of. This is shaping up, we should be able to get that landed fairly soon, just need to hear from this group if there’s objections on naming or status of this? + +Rod: Myself and Trevor still don’t like the name. I’m not willing to object too strongly to that. + +Bert: The names are ugly, but I don’t want to bikeshed. Same as Rod, I guess. + +James: If I could ask folks to do a final review, it’s a big PR. All buffer uses in core are updated to use this. Let me know if there’s any objections. I’d like to get this landed before too long. + +Trevor: The documentation changes are what took me the longest to get through. + +Rod: Documenting this stuff has caused problems in the past. + +### Check in ICU into repo? [#3476](https://github.com/nodejs/node/issues/3476 ) - Steven R. Loomis - +1 on checking in <45M into repo? so Jenkins servers will never again have to download ICU + +Steven: Speaking of massive PRs! I haven’t created the PR for this. I have been doing some slicing on ICU, I have now a 45mb branch that includes all of ICU, enough to build a full set or a full-icu, or a small icu, and removes the requirements for the servers to download anything at all at build time. I’m asking for sign-off on this. It would make small-icu the default for `./configure`. + +Steven: it will be located in source: `deps/icu` + +Trevor: How often would this need to be updated? + +Steven: [CD - missed this] + +Trevor: A good chunk of the deps/v8 updates include tarballs. + +Ben: Does it write the data files at compile-time? + +Steven: This just checks in the binary blobs. + +Ben: In that case Trevor makes a good point. + +Steven: The data file is not compressed, it does compress fairly easily. (59% by gzip) + +Trevor: One of the original reason for not landing this was that the source files were 200mb, but when they’re compressed down they’re 45mb. Git works better with the former. We’d almost have to do a test to see which is a more sustainable in the long run. + +Steven: Including the source data means that the source data has to be compiled which takes a long time. (+75M source + tools) + +update schedule - http://source.icu-project.org/repos/icu/data/trunk/meta/xml/icumeta.json + +Trevor: We’ve discussed all of this. If we just include English, how do we present this on the website? There’s a lot of contention + +Rod: I’ve had trouble getting my license updater to work because not having it in-repo breaks things. On the other hand, the repo is growing at a fast pace, and it’s pretty bad UX (have you ever tried cloning the Mozilla repo?) + +Chris: It seems like including the full source + +Steven: We could do the 20mb, only 3mb of which is the binary blob. And we could pick it up every year. full data available via npm (see next issue) + +Ben: what about security releases? Do those require updating the binary blob? + +Steven: No. + +Trevor: My only concern is the binary blobs. + +Rod: Let’s start with the small binary blob will allay a lot of our concerns here. + +Steven: I may be able to slice the 20mb more. This is with no configure source changes to ICU. It may be further reducible. + +### Detect ICU data at startup? [#3460](https://github.com/nodejs/node/issues/3460 ) - Steven R. Loomis - +1 on ≈/node_modules/.node-icu ? + +Steven: This is the companion to the above. The basic idea here is that I went through the resolver code and what I’m proposing is having the data files in a directory inside of `node_modules/.node-icu`, installed by npm module or by some other installer could install it to that directory. + +Trevor: Has there been any thought to some sort of integration with npm? + +Steven: I hadn’t thought about that. Nathan had commented much earlier, concerned with linkage between Node and npm. This only uses the node_modules directory, not npm itself. +Chris to point CLI team at issue. + +### Other business + +_Discussed decision making process around the Promises PR_ + +## Next Meeting + +2016-02-24 diff --git a/meetings/2016-05-04.md b/meetings/2016-05-04.md new file mode 100644 index 0000000..3b5abb7 --- /dev/null +++ b/meetings/2016-05-04.md @@ -0,0 +1,192 @@ +# Node Foundation CTC Meeting 2016-05-04 + +## Links + +* **Audio Recording**: https://www.youtube.com/watch?v=3M95wsWs7qQ +* **GitHub Issue**: https://github.com/nodejs/node/issues/6567 +* **Minutes Google Doc**: +* _Previous Minutes Google Doc: _ + +## Present + +* Bradley Farias @bmeck (observer/modules EPS/GoDaddy) +* Brian Terlson @bterlson (observer/modules EPS/tc39/Microsoft) +* Сковорода Никита Андреевич @ChALkeR (CTC) +* Colin Ihrig @cjihrig (CTC) +* Evan Lucas @evanlucas (CTC) +* Jeremiah Senkpiel @Fishrock123 (CTC) +* James M Snell @jasnell (CTC) +* Josh Gavant (observer/Microsoft) +* Michael Dawson @mhdawson (CTC) +* Brian White @mscdex (CTC) +* Rod Vagg @rvagg (CTC) +* Seth Thompson (observer/Google) +* Shigeki Ohtsu @shigeki (CTC) +* Steven R Loomis @srl295 (observer/IBM/ICU) +* Trevor Norris @trevnorris (CTC) +* Rich Trott @Trott (CTC) + + +## Agenda + +Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +### nodejs/node + +* Revert 5950 [#6537](https://github.com/nodejs/node/pull/6537) +* src: refactor constants, deprecate require('constants') [#6534](https://github.com/nodejs/node/pull/6534) +* doc: refactor the changelog by version [#6503](https://github.com/nodejs/node/pull/6503) +* Request for discussion of https://github.com/dherman/defense-of-dot-js vs EPS on modules + + + +## Standup + +* Сковорода Никита Андреевич: + * Nothing too significant, some comments (as usual). + +* Colin Ihrig: + * A few PRs + * Reviewing issues and PRs + +* Evan Lucas: + * Submitted a doc and util pr. + * Working on a http bug. + * Been trying to help some packages get updated to work with v6. + * Left some comments on a few issues. + * Have been working on a commit validator tool. + +* Jeremiah Senkpiel: + * v6 Breaking changes doc + * working on v6.1.0 release + * assorted PRs, Issues, EPs -- done a bunch of reviews + +* James M Snell: + * v6 Release + * Fixed 2 util.inspect bugs (proxy and array length) + * Helped troubleshoot buffer indexOf/lastIndexOf bug + * Troubleshooting 5950 issues + * Work on error code refactoring + * Work on constants refactoring + * Work on changelog refactoring + * Ongoing http implementation security / spec compliance review + * Working on compliance follow ups from vm summit + * Investigating possible alternative solutions for stdout/stderr + non-blocking issues + +* Josh Gavant: + * Testing use of trace-event macros, designing tracing module, reviewing AsyncWrap and alternatives. + +* Michael Dawson: + * Investigated ppc be release machine issues + * validating be build from nightly release job + * AsyncWrap EP review + * switched benchmarking vof v6 over to new v6 branch + * wrote/submitted stable ABI module EP + * misc reviews/lands + +* Brian White: + * Worked on http server code refactor and other http performance improvements + * Reviewed PRs/issues + +* Rod Vagg: + * Time off, now catching up + +* Seth Thompson: + * continue to work on getting v8 inspector to work with node + * meeting with Ali as he.s visiting in person + +* Shigeki Ohtsu: + * Upgrading openssl and reviewing one PR for GCM IV + +* Steven R Loomis: + * turn/rebase/clean ci for https://github.com/nodejs/node/pull/6088 ( checkin ICU into master ) and https://github.com/nodejs/node/pull/4253 ( v8BreakIterator to throw error rather than fatal crash + * opened Doodle poll to get Intl WG going again (monthly) https://github.com/nodejs/Intl/issues/33 + +* Trevor Norris: + * Don't abort on access of invalid pointer returned by Unwrap PR + * Tuning the AsyncWrap EP and writing patches as result + +* Rich Trott: + * Added undocumented-for-now -F flag to jslint.js to automatically fix lint issues. Dog-fooding it right now. Give it a shot if you.re brave. + * Open PR to have `known_issues` tests run via CI and `make test`. PTAL. https://github.com/nodejs/node/pull/6559 + * Assessments for long-dormant issues. + +* Bradley Farias: + * Investigated counter proposal details to node EP for modules + * Started test framework for modules EP + + +## Review of last meeting + + +* governance: add new collaborators XII [#6282](https://github.com/nodejs/node/issues/6282) +* doc: doc-only deprecation for util.log() [#6161](https://github.com/nodejs/node/pull/6161) +* Check (small) ICU into repo [#6088](https://github.com/nodejs/node/pull/6088) +* doc, tls: deprecate createSecurePair [#6063](https://github.com/nodejs/node/pull/6063) +* Planning for v6 [#5766](https://github.com/nodejs/node/issues/5766) +* Introduce staging branch for stable release streams [#6306](https://github.com/nodejs/node/issues/6306) +* ES6 Modules detection update / https://github.com/nodejs/node-eps/issues/13 + + +## Minutes + +### Revert 5950 [#6537](https://github.com/nodejs/node/pull/6537) +* James: Bug picked up in v6 for symlinked peer dependencies, our tests/CI didn.t pick it up unfortunately. Proposal is to revert the change and review it after adding some tests for this. +* Rod: there was some discussion about a revert being semver major +* Jeremiah: not optimal, reverting is technically a semver-major +* Rod: does anyone have an objection to a revert at this stage? +* Jeremiah: I believe some of the new behaviour was useful, is there a path to reintroducing it? +* James: least invasive route would be to add the new behaviour behind a flag, there are some other approaches being investigated. The folks who proposed this change in the first place are behind the reversion at this stage. + +### Request for discussion of https://github.com/dherman/defense-of-dot-js vs EPS on modules + + +* Bradley: we merged our proposal last week and afterward a counter-proposal (that we.ve been waiting on for many weeks) showed up. The proposal is a package.json-based solution. It does address all of the major use-cases of Node and it does this in slightly different ways than we.ve seen before. It.s still lacking some existing behaviour of CJS files (you can.t detect some filepaths for CJS), e.g. ~/.config.js. It introduces a path-expansion mechanism. You add a module.root to your package.json. I still have concerns about this but it.s much better than the previous ones based on package.json. I.ll be having a more in-depth conversation with Brian Terlson (TC39/Microsoft), if anyone wants to join. +* Jeremiah: is the main downside of the file extension about sharing files from servers that aren.t configured for it? +* Bradley: yes, the main concern is about firewalls and configs that block transmission of the new files. +* Rod: can you help us empathise with the sentimentality around the file extension, are there objective problems that we are not picking up on? +* Bradley: there.s a concern . _something about a lodash example_ . shell scripts not finding the new files with *.js. +* Brian Terlson: there.s an expectation that JavaScript is contained in a .js file and we.re in a nice place now that this is true with some minor exceptions. For TypeScript we.d have to add a .mts and .mtsx extension. +* Rod: _asking about the sentimentality again_ +* Brian Terlson: that.s a mischaracterisation of the defense of .js proposal +* Jeremiah: there will be developer friction either way +* Brian Terlson: but friction will be limited to node developers as opposed to all javascript developers +* Rod: what state is standard ? +* Bradley: Some pieces still have minor changes going on but mostly locked down. +* Brian Terlson: we have been thinking about all of these kinds of things during the whole process. I don.t think spec changes are off the table, TC39 could reconsider some aspects of the spec to improve matters. No promises, but don.t feel like you shouldn.t bring it up because we.re so late in process. +* Bradley: forward detection is the main problem. Have examples of specifics. As long as implicit strict mode is enforced we are going to have a hard time. +Rod: what.s the path forward ? On our side seems like strong preference is still on the file extension side. +* Bradley: Either way was ecosystem effects. Personally towards file extensions, most response on social media is either .better than nothing. or .don.t like file extension but not pushing for package.json either.. Will discuss further with Brian and others from Microsoft. +* Rod: EP does not mean it is final, but it does mean it is the preferred way forward and CTC members would have to be convinced otherwise. +* Bradley: likely need longer discussion in next week or so either way. + + +### src: refactor constants, deprecate require('constants') [#6534](https://github.com/nodejs/node/pull/6534) +* James: recent PR asking to add new constant. They are mentioned in the docs in a few places, but not well documented. Figured should take a run at documenting and refactoring to make it make more sense. Cleans up the structure and properly documents. Would it be semver major since we have never documented before ? +* Jeremiah: marked as semver major because it was deprecating existing constants. +* James: hard deprecation pretty much blows up everything as npm uses them ,etc. Thats why it is a soft deprecation. +* Jerimiah: we should find way to document +* James: add to release notes saying to use the new versions. +* Rich: Move discussion back to github +* Rod: Any objection to doing this, want consensus before we spend a lot of time doing it. + + +### doc: refactor the changelog by version [#6503](https://github.com/nodejs/node/pull/6503) + +* James: changelog grew to point where it is no longer visible/usable on github. To make it at least visible it was temporarily split out into an archive. This PR is to split it out by version instead. Each version release would link to the individual version change log. One at top level becomes an index to the version specific ones. Acceptable or do we need another approach? Archive for io.js release and before v.10. Should not add too much additional work to release process. +* Rod: maybe io.js ones should be in separate files as well instead archive. +* Jeremiah: io.js v1 has particularly large set of changes +* James: any major objections ? +* Rod: take it back to github, roll forward unless objections on github. + +### Q/A on public fora +* call for questions on public channels. +* no existing ones so far. +* will wait a few minutes to see if any come in +* ok moving on. + + +## Next Meeting + +2016-05-11 diff --git a/meetings/2016-06-15.md b/meetings/2016-06-15.md new file mode 100644 index 0000000..6fce3b0 --- /dev/null +++ b/meetings/2016-06-15.md @@ -0,0 +1,174 @@ +# Node Foundation CTC Meeting 2016-06-15 + +## Links + +* **Audio Recording**: https://www.youtube.com/watch?v=qWX8i9SKatQ +* **GitHub Issue**: https://github.com/nodejs/node/issues/7307 +* **Minutes Google Doc**: +* _Previous Minutes Google Doc: _ + +## Present + +* Bradley Meck @bmeck (observer/GoDaddy) +* Сковорода Никита Андреевич @ChALkeR (CTC) +* Chris Dickinson @chrisdickinson (CTC) +* Evan Lucas @evanlucas (CTC) +* Jeremiah Senkpiel @Fishrock123 (CTC) +* John-David Dalton @jdalton (observer/Microsoft) +* Josh Gavant @joshgav (observer/Microsoft) +* Michael Dawson @mhdawson (CTC) +* Brian White @mscdex (CTC) +* Ali Ijaz Sheikh @ofrobots (CTC) +* Alexis Campailla @orangemocha (CTC) +* Rod Vagg @rvagg (CTC) +* Rich Trott @Trott (CTC) +* Trevor Norris @trevnorris (CTC) + +## Agenda + +Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +### nodejs/node + +* url: return valid file: urls fom url.format() [#7234](https://github.com/nodejs/node/pull/7234) +* http: don't inherit from Object.prototype [#6102](https://github.com/nodejs/node/pull/6102) + +### Standup + +* Bradley Meck @bmeck + * fleshing out a proposal for if we could disambiguate the grammars for Script and Module. + +* Сковорода Никита Андреевич @ChALkeR (CTC) + * some issue/PRs reviews + +* Chris Dickinson @chrisdickinson (CTC) + * NodeConf + * modules.guide + +* Evan Lucas @evanlucas (CTC) + * Preparing for security release + +* Jeremiah Senkpiel @Fishrock123 (CTC) + * (Previous week: fixed the primary OS X stdio bug) + * NodeConf + +* Fedor Indutny @indutny (CTC) + * fixing bugs, reviewing PRs, working on llnode + +* Josh Gavant @joshgav + * debug protocol stuff + +* Michael Dawson @mhdawson (CTC) + * Still chasing PPC machine issues + * AIX/malloc(0) issue + * ABI stable module API work with Stefan/Ian, filling in Nan examples + * Input on some benchmarking related PRs + * Other misc reviews/lands + * Keeping up with issues + +* Brian White @mscdex (CTC) + * Landed some old PRs + * Submitting PRs to fix some regressions + * Reviewed PRs and issues + +* Ali Ijaz Sheikh @ofrobots (CTC) + * More work on v8_inspector + * Starting to look at backporting some V8 fixes for LTS + +* Alexis Campailla @orangemocha (CTC) + * Landed a fix for node-gyp, broke with VS update 3 + +* Rod Vagg @rvagg (CTC) + * Alpine Linux in CI + * Security release hoo haa + * Reviews & discussions + * Electron / Node relationship + * New CTC repo + * Jenkins upkeep + +* Rich Trott @Trott (CTC) + * Setting up the next onboarding + * Facilitated a session on releases at NodeConf. Will share notes with Build WG, LTS WG, and people who can sign releases. + +* Trevor Norris @trevnorris (CTC) + * Finished updating AsyncWrap EP and now investigating proposed implementation. + * Helping identify old issue in Atom editor in regards to writing to disk. + + +### Review of last meeting +* Tracking issue: stdio problems [#6980](https://github.com/nodejs/node/issues/6980) +* module: expose `Module._runInThisContext` [#6288](https://github.com/nodejs/node/pull/6288) + + +## Minutes + + +### url: return valid file: urls from url.format() [#7234](https://github.com/nodejs/node/pull/7234) + +@trott: semver-major change, needs approval from CTC. +Real fix will be @jasnell’s HTTP compliance work. + +In browsers `file:/home/joshgav/myfile.txt` is auto-corrected to `file:///home/joshgav/myfile.txt` (i.e. slashes are prepended to the path and hostname is an empty string). This change institutes the same in Node.js. + +Are there other protocols which require additional slashes (`//`) if hostname isn’t specified? Yes, but hard to heuristically determine if needed. + + +### http: don't inherit from Object.prototype [#6102](https://github.com/nodejs/node/pull/6102) + +Replace headers object ({}) in req/res with StorageObject, which doesn’t delegate to Object.prototype. But this will break anyone using regular `Object` methods on header props. + +@trevnorris: Why don’t we intercept calls to properties with checks to an internal dictionary of actual headers? If the key isn’t there, then try to call Object.prototype. + +How would that effect perf? + +It’s the right decision because otherwise can’t use headers with certain names like `__proto__`. + +Better to do a deprecation cycle. How? Insert something (proxy) between actual call to property, would issue deprecation warning first. This would be temporary, eventually this interceptor/proxy would go away. + + +### ES6 Modules [node-eps/002-es6-modules.md](https://github.com/nodejs/node-eps/blob/master/002-es6-modules.md) + +Need to disambiguate ES6 modules and regular scripts (which include CJS modules). Cannot determine if file is module, script, etc. from code itself. For this reason Node decided to use `.mjs` extension for ES6 modules. + +New proposal: If `import` or `export` keywords are in module code, then use module goal. So no need for extra metadata or file extension. But would have to parse file to check for presence of these keywords. + +https://github.com/bmeck/UnambiguousJavaScriptGrammar +replaces https://github.com/nodejs/node-eps/blob/master/002-es6-modules.md#51-determining-if-source-is-an-es-module + +This would be part of ECMA262 so browsers would do the same, but needs to be ironed out in TC39. On [agenda][TC39 Agenda] for 7/26 TC39 meeting. + +What if nothing is imported or exported? Could do `export default null` to export nothing. + +Starting off, preferred goal when preparing code would be CommonJS/script, later on could change to ES6/module. + +Caching is more feasible. + +Provides more seamless flow from CJS to ES6 in the future. + +Will packaging tools need to implement parsing logic too to package properly? Yes, but there are possibilities listed in the repo. + +What other differences between scripts and modules? +- `await` keyword only in modules according to ECMA262 +- `modules.root` in package.json is intended to allow mirrored directory structure for use with ES6; but technically all it does is redirect file system calls and it could be used for other purposes, so it’s not reliable. + +Purpose of modules.root - allows redirection within a module, e.g. `module/file.js` doesn’t necessarily resolve to `./file.js` within the directory, could be redirected to `${module.root}/file.js`. This allows side-by-side CJS and ES6 among other things. + +What about for human reading? How can people differentiate at a glance between CJS and ES6? +- `import`’s are generally at the top, `export`s at the bottom. If you see `import` it’s an ES6 module. + +How are browsers dealing with this? Older browsers which encounter `