From 34405ddb83ca768cca22a8e978a106dc2298219e Mon Sep 17 00:00:00 2001 From: James M Snell Date: Mon, 7 Nov 2016 08:26:19 -0800 Subject: [PATCH] doc: move TSC and CTC meeting minutes out of core repo The TSC and CTC meeting minutes are more properly placed in the nodejs/tsc and nodejs/ctc repositories, respectively. PR-URL: https://github.com/nodejs/node/pull/9503 Reviewed-By: Colin Ihrig Reviewed-By: Myles Borins Reviewed-By: Michael Dawson Reviewed-By: Evan Lucas Reviewed-By: Rich Trott Reviewed-By: Luigi Pinca Reviewed-By: Roman Reiss --- doc/ctc-meetings/2015-10-28.md | 276 ------------------ doc/ctc-meetings/2016-05-04.md | 192 ------------ doc/ctc-meetings/2016-06-15.md | 174 ----------- doc/ctc-meetings/2016-06-22.md | 151 ---------- doc/ctc-meetings/2016-06-29.md | 187 ------------ doc/ctc-meetings/2016-07-06.md | 150 ---------- doc/ctc-meetings/2016-07-13.md | 236 --------------- doc/ctc-meetings/2016-07-20.md | 202 ------------- doc/ctc-meetings/2016-07-27.md | 237 --------------- doc/ctc-meetings/2016-08-03.md | 336 --------------------- doc/ctc-meetings/2016-08-10.md | 281 ------------------ doc/ctc-meetings/2016-08-17.md | 300 ------------------- doc/ctc-meetings/2016-08-24.md | 328 --------------------- doc/ctc-meetings/2016-08-31.md | 315 -------------------- doc/ctc-meetings/2016-09-07.md | 245 ---------------- doc/ctc-meetings/2016-09-14.md | 153 ---------- doc/ctc-meetings/2016-09-21.md | 218 -------------- doc/ctc-meetings/2016-09-28.md | 302 ------------------- doc/ctc-meetings/2016-10-05.md | 311 -------------------- doc/ctc-meetings/2016-10-12.md | 157 ---------- doc/ctc-meetings/2016-10-19.md | 202 ------------- doc/ctc-meetings/2016-10-26.md | 151 ---------- doc/tsc-meetings/2015-05-27.md | 143 --------- doc/tsc-meetings/2015-06-03.md | 166 ----------- doc/tsc-meetings/2015-06-10.md | 184 ------------ doc/tsc-meetings/2015-06-17.md | 134 --------- doc/tsc-meetings/2015-07-01.md | 88 ------ doc/tsc-meetings/2015-07-08.md | 131 --------- doc/tsc-meetings/2015-07-15.md | 94 ------ doc/tsc-meetings/2015-07-22.md | 168 ----------- doc/tsc-meetings/2015-07-29.md | 89 ------ doc/tsc-meetings/2015-08-12.md | 87 ------ doc/tsc-meetings/2015-08-19.md | 120 -------- doc/tsc-meetings/2015-08-26.md | 112 ------- doc/tsc-meetings/2015-09-02.md | 418 --------------------------- doc/tsc-meetings/2015-09-16.md | 116 -------- doc/tsc-meetings/2015-09-30.md | 161 ----------- doc/tsc-meetings/2015-10-07.md | 102 ------- doc/tsc-meetings/2015-10-14.md | 121 -------- doc/tsc-meetings/2015-10-21.md | 214 -------------- doc/tsc-meetings/io.js/2014-10-09.md | 61 ---- doc/tsc-meetings/io.js/2014-10-15.md | 44 --- doc/tsc-meetings/io.js/2014-10-29.md | 33 --- doc/tsc-meetings/io.js/2014-12-10.md | 139 --------- doc/tsc-meetings/io.js/2014-12-17.md | 91 ------ doc/tsc-meetings/io.js/2014-12-30.md | 95 ------ doc/tsc-meetings/io.js/2015-01-07.md | 154 ---------- doc/tsc-meetings/io.js/2015-01-13.md | 101 ------- doc/tsc-meetings/io.js/2015-01-21.md | 166 ----------- doc/tsc-meetings/io.js/2015-01-28.md | 179 ------------ doc/tsc-meetings/io.js/2015-02-04.md | 107 ------- doc/tsc-meetings/io.js/2015-02-18.md | 129 --------- doc/tsc-meetings/io.js/2015-03-04.md | 164 ----------- doc/tsc-meetings/io.js/2015-03-18.md | 92 ------ doc/tsc-meetings/io.js/2015-04-01.md | 107 ------- doc/tsc-meetings/io.js/2015-04-08.md | 184 ------------ doc/tsc-meetings/io.js/2015-04-15.md | 87 ------ doc/tsc-meetings/io.js/2015-04-22.md | 127 -------- doc/tsc-meetings/io.js/2015-04-29.md | 101 ------- doc/tsc-meetings/io.js/2015-05-13.md | 137 --------- 60 files changed, 10050 deletions(-) delete mode 100644 doc/ctc-meetings/2015-10-28.md delete mode 100644 doc/ctc-meetings/2016-05-04.md delete mode 100644 doc/ctc-meetings/2016-06-15.md delete mode 100644 doc/ctc-meetings/2016-06-22.md delete mode 100644 doc/ctc-meetings/2016-06-29.md delete mode 100644 doc/ctc-meetings/2016-07-06.md delete mode 100644 doc/ctc-meetings/2016-07-13.md delete mode 100644 doc/ctc-meetings/2016-07-20.md delete mode 100644 doc/ctc-meetings/2016-07-27.md delete mode 100644 doc/ctc-meetings/2016-08-03.md delete mode 100644 doc/ctc-meetings/2016-08-10.md delete mode 100644 doc/ctc-meetings/2016-08-17.md delete mode 100644 doc/ctc-meetings/2016-08-24.md delete mode 100644 doc/ctc-meetings/2016-08-31.md delete mode 100644 doc/ctc-meetings/2016-09-07.md delete mode 100644 doc/ctc-meetings/2016-09-14.md delete mode 100644 doc/ctc-meetings/2016-09-21.md delete mode 100644 doc/ctc-meetings/2016-09-28.md delete mode 100644 doc/ctc-meetings/2016-10-05.md delete mode 100644 doc/ctc-meetings/2016-10-12.md delete mode 100644 doc/ctc-meetings/2016-10-19.md delete mode 100644 doc/ctc-meetings/2016-10-26.md delete mode 100644 doc/tsc-meetings/2015-05-27.md delete mode 100644 doc/tsc-meetings/2015-06-03.md delete mode 100644 doc/tsc-meetings/2015-06-10.md delete mode 100644 doc/tsc-meetings/2015-06-17.md delete mode 100644 doc/tsc-meetings/2015-07-01.md delete mode 100644 doc/tsc-meetings/2015-07-08.md delete mode 100644 doc/tsc-meetings/2015-07-15.md delete mode 100644 doc/tsc-meetings/2015-07-22.md delete mode 100644 doc/tsc-meetings/2015-07-29.md delete mode 100644 doc/tsc-meetings/2015-08-12.md delete mode 100644 doc/tsc-meetings/2015-08-19.md delete mode 100644 doc/tsc-meetings/2015-08-26.md delete mode 100644 doc/tsc-meetings/2015-09-02.md delete mode 100644 doc/tsc-meetings/2015-09-16.md delete mode 100644 doc/tsc-meetings/2015-09-30.md delete mode 100644 doc/tsc-meetings/2015-10-07.md delete mode 100644 doc/tsc-meetings/2015-10-14.md delete mode 100644 doc/tsc-meetings/2015-10-21.md delete mode 100644 doc/tsc-meetings/io.js/2014-10-09.md delete mode 100644 doc/tsc-meetings/io.js/2014-10-15.md delete mode 100644 doc/tsc-meetings/io.js/2014-10-29.md delete mode 100644 doc/tsc-meetings/io.js/2014-12-10.md delete mode 100644 doc/tsc-meetings/io.js/2014-12-17.md delete mode 100644 doc/tsc-meetings/io.js/2014-12-30.md delete mode 100644 doc/tsc-meetings/io.js/2015-01-07.md delete mode 100644 doc/tsc-meetings/io.js/2015-01-13.md delete mode 100644 doc/tsc-meetings/io.js/2015-01-21.md delete mode 100644 doc/tsc-meetings/io.js/2015-01-28.md delete mode 100644 doc/tsc-meetings/io.js/2015-02-04.md delete mode 100644 doc/tsc-meetings/io.js/2015-02-18.md delete mode 100644 doc/tsc-meetings/io.js/2015-03-04.md delete mode 100644 doc/tsc-meetings/io.js/2015-03-18.md delete mode 100644 doc/tsc-meetings/io.js/2015-04-01.md delete mode 100644 doc/tsc-meetings/io.js/2015-04-08.md delete mode 100644 doc/tsc-meetings/io.js/2015-04-15.md delete mode 100644 doc/tsc-meetings/io.js/2015-04-22.md delete mode 100644 doc/tsc-meetings/io.js/2015-04-29.md delete mode 100644 doc/tsc-meetings/io.js/2015-05-13.md diff --git a/doc/ctc-meetings/2015-10-28.md b/doc/ctc-meetings/2015-10-28.md deleted file mode 100644 index 5efe94454ad3f8..00000000000000 --- a/doc/ctc-meetings/2015-10-28.md +++ /dev/null @@ -1,276 +0,0 @@ -# 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/doc/ctc-meetings/2016-05-04.md b/doc/ctc-meetings/2016-05-04.md deleted file mode 100644 index 3b5abb7ad98901..00000000000000 --- a/doc/ctc-meetings/2016-05-04.md +++ /dev/null @@ -1,192 +0,0 @@ -# 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/doc/ctc-meetings/2016-06-15.md b/doc/ctc-meetings/2016-06-15.md deleted file mode 100644 index 87fc0dc243d3a2..00000000000000 --- a/doc/ctc-meetings/2016-06-15.md +++ /dev/null @@ -1,174 +0,0 @@ -# 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. - -[TC39 Agenda]: https://github.com/tc39/agendas/blob/master/2016/07.md - -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 `