Browse Source

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 <cjihrig@gmail.com>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Evan Lucas <evanlucas@me.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Roman Reiss <me@silverwind.io>
v6
James M Snell 8 years ago
parent
commit
976fe250f5
  1. 276
      doc/ctc-meetings/2015-10-28.md
  2. 65
      doc/ctc-meetings/2015-11-04.md
  3. 136
      doc/ctc-meetings/2015-11-11.md
  4. 83
      doc/ctc-meetings/2015-12-02.md
  5. 164
      doc/ctc-meetings/2015-12-16.md
  6. 216
      doc/ctc-meetings/2016-01-06.md
  7. 337
      doc/ctc-meetings/2016-01-20.md
  8. 295
      doc/ctc-meetings/2016-01-27.md
  9. 223
      doc/ctc-meetings/2016-02-03.md
  10. 167
      doc/ctc-meetings/2016-02-10.md
  11. 240
      doc/ctc-meetings/2016-02-17.md
  12. 192
      doc/ctc-meetings/2016-05-04.md
  13. 174
      doc/ctc-meetings/2016-06-15.md
  14. 151
      doc/ctc-meetings/2016-06-22.md
  15. 187
      doc/ctc-meetings/2016-06-29.md
  16. 150
      doc/ctc-meetings/2016-07-06.md
  17. 236
      doc/ctc-meetings/2016-07-13.md
  18. 202
      doc/ctc-meetings/2016-07-20.md
  19. 237
      doc/ctc-meetings/2016-07-27.md
  20. 336
      doc/ctc-meetings/2016-08-03.md
  21. 281
      doc/ctc-meetings/2016-08-10.md
  22. 300
      doc/ctc-meetings/2016-08-17.md
  23. 328
      doc/ctc-meetings/2016-08-24.md
  24. 315
      doc/ctc-meetings/2016-08-31.md
  25. 245
      doc/ctc-meetings/2016-09-07.md
  26. 153
      doc/ctc-meetings/2016-09-14.md
  27. 218
      doc/ctc-meetings/2016-09-21.md
  28. 303
      doc/ctc-meetings/2016-09-28.md
  29. 312
      doc/ctc-meetings/2016-10-05.md
  30. 157
      doc/ctc-meetings/2016-10-12.md
  31. 202
      doc/ctc-meetings/2016-10-19.md
  32. 151
      doc/ctc-meetings/2016-10-26.md
  33. 143
      doc/tsc-meetings/2015-05-27.md
  34. 166
      doc/tsc-meetings/2015-06-03.md
  35. 184
      doc/tsc-meetings/2015-06-10.md
  36. 134
      doc/tsc-meetings/2015-06-17.md
  37. 88
      doc/tsc-meetings/2015-07-01.md
  38. 131
      doc/tsc-meetings/2015-07-08.md
  39. 94
      doc/tsc-meetings/2015-07-15.md
  40. 168
      doc/tsc-meetings/2015-07-22.md
  41. 89
      doc/tsc-meetings/2015-07-29.md
  42. 87
      doc/tsc-meetings/2015-08-12.md
  43. 120
      doc/tsc-meetings/2015-08-19.md
  44. 112
      doc/tsc-meetings/2015-08-26.md
  45. 418
      doc/tsc-meetings/2015-09-02.md
  46. 116
      doc/tsc-meetings/2015-09-16.md
  47. 161
      doc/tsc-meetings/2015-09-30.md
  48. 102
      doc/tsc-meetings/2015-10-07.md
  49. 121
      doc/tsc-meetings/2015-10-14.md
  50. 214
      doc/tsc-meetings/2015-10-21.md
  51. 61
      doc/tsc-meetings/io.js/2014-10-09.md
  52. 44
      doc/tsc-meetings/io.js/2014-10-15.md
  53. 33
      doc/tsc-meetings/io.js/2014-10-29.md
  54. 139
      doc/tsc-meetings/io.js/2014-12-10.md
  55. 91
      doc/tsc-meetings/io.js/2014-12-17.md
  56. 95
      doc/tsc-meetings/io.js/2014-12-30.md
  57. 154
      doc/tsc-meetings/io.js/2015-01-07.md
  58. 101
      doc/tsc-meetings/io.js/2015-01-13.md
  59. 166
      doc/tsc-meetings/io.js/2015-01-21.md
  60. 179
      doc/tsc-meetings/io.js/2015-01-28.md
  61. 107
      doc/tsc-meetings/io.js/2015-02-04.md
  62. 129
      doc/tsc-meetings/io.js/2015-02-18.md
  63. 164
      doc/tsc-meetings/io.js/2015-03-04.md
  64. 92
      doc/tsc-meetings/io.js/2015-03-18.md
  65. 107
      doc/tsc-meetings/io.js/2015-04-01.md
  66. 184
      doc/tsc-meetings/io.js/2015-04-08.md
  67. 87
      doc/tsc-meetings/io.js/2015-04-15.md
  68. 127
      doc/tsc-meetings/io.js/2015-04-22.md
  69. 101
      doc/tsc-meetings/io.js/2015-04-29.md
  70. 137
      doc/tsc-meetings/io.js/2015-05-13.md

276
doc/ctc-meetings/2015-10-28.md

@ -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**: <https://docs.google.com/document/d/1GsTF3no6bimA20hi9i5aTBudBSM8jzPvuODR01hOltc>
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/1ad8Xlza_B-iWexdlAd1Z5muzBy_HH88t_iSD31OUepA>_
## 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

65
doc/ctc-meetings/2015-11-04.md

@ -1,65 +0,0 @@
# 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**: <https://docs.google.com/document/d/1BlgxBLqnoK6slwAkGXUcIy7CFh1m9ZyLo_D_ABcw6vc>
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/1GsTF3no6bimA20hi9i5aTBudBSM8jzPvuODR01hOltc>_
## 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

136
doc/ctc-meetings/2015-11-11.md

@ -1,136 +0,0 @@
# 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**: <https://docs.google.com/document/d/1tkZ4BV9h7jbbbVBU8hLoLHw9cEgAOt3gtgKXxU8AUh0>
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/1BlgxBLqnoK6slwAkGXUcIy7CFh1m9ZyLo_D_ABcw6vc>_
## 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

83
doc/ctc-meetings/2015-12-02.md

@ -1,83 +0,0 @@
# 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**: <https://docs.google.com/document/d/1fCXy_N0kGISl7JEPf6g1n15eJ_ZcebUPzNA0Mkd79Lc>
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/1ZqK0uKe5wAxNB8v9EwV2DtsYHBvBxJdv3zM0Ldc9RW0>_
## 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

164
doc/ctc-meetings/2015-12-16.md

@ -1,164 +0,0 @@
# 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**: <https://docs.google.com/document/d/1084kuafyFax-1dymqvMlVUPvu3apdzw0ZM_4FX3z1RM>
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/1fCXy_N0kGISl7JEPf6g1n15eJ_ZcebUPzNA0Mkd79Lc>_
## 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?
`<crickets>`
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

216
doc/ctc-meetings/2016-01-06.md

@ -1,216 +0,0 @@
# 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**: <https://docs.google.com/document/d/1LyECbnYZcxPoBal9JA8quGEvie1Rj_ofKn4CVMni9eY>
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/1084kuafyFax-1dymqvMlVUPvu3apdzw0ZM_4FX3z1RM>_
## 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

337
doc/ctc-meetings/2016-01-20.md

@ -1,337 +0,0 @@
# 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**: <https://docs.google.com/document/d/1X3RbJhhLvFNojmQwxmsfUb2qPMyNPcVzcSS2aAoAon0>
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/1084kuafyFax-1dymqvMlVUPvu3apdzw0ZM_4FX3z1RM>_
## 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

295
doc/ctc-meetings/2016-01-27.md

@ -1,295 +0,0 @@
# 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**: <https://docs.google.com/document/d/145ND-9pGdAwZ1eoOMypX1_wtx5FCVoanWtLl8zzyxH8>
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/1X3RbJhhLvFNojmQwxmsfUb2qPMyNPcVzcSS2aAoAon0>_
## 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! `</sarcasm>`
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

223
doc/ctc-meetings/2016-02-03.md

@ -1,223 +0,0 @@
# 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**: <https://docs.google.com/document/d/145ND-9pGdAwZ1eoOMypX1_wtx5FCVoanWtLl8zzyxH8>
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/1X3RbJhhLvFNojmQwxmsfUb2qPMyNPcVzcSS2aAoAon0>_
## 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/<something>`.
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

167
doc/ctc-meetings/2016-02-10.md

@ -1,167 +0,0 @@
# 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**: <https://docs.google.com/document/d/1sAHu9jVh8Dn9gHFASOH56j2klzW-L6YP-DfKo1gO_6Y>
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/145ND-9pGdAwZ1eoOMypX1_wtx5FCVoanWtLl8zzyxH8>_
## 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

240
doc/ctc-meetings/2016-02-17.md

@ -1,240 +0,0 @@
# 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**: <https://docs.google.com/document/d/1Y9p8EopccPOj1v4gDbnor2kvlHvkbHxankWuRKHssyo>
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/1sAHu9jVh8Dn9gHFASOH56j2klzW-L6YP-DfKo1gO_6Y>_
## 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

192
doc/ctc-meetings/2016-05-04.md

@ -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**: <https://docs.google.com/document/d/1eP0HyB452ZmoMlljCXJNyWO-BZyhzo9j6kNn17sDCEg>
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/16t1um6sXBlFZT2aCLqnlwumcEcM2K-_xeEFnnsA_rBQ>_
## 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

174
doc/ctc-meetings/2016-06-15.md

@ -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**: <https://docs.google.com/document/d/1e7JdFHVtMtW9_o0Gi3NNz6g7TK50q4u9LYKFzBeHOQ8>
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/1G_sywyzJFPDzLv-KiG21L_4cIAP9_awQnP00ox8Nyiw>_
## 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 `<script type=”module”>` and don’t recognize the type will skip it. Loading is asynchronous by default.
Are browsers concerned about transition period from CJS to ES6? How do they load older scripts, e.g. jQuery?
**Should Node move this forward as alternative to `.mjs` proposal?**
TBD. What does TC39 think of this? It’s on agenda for next F2F (see above).
### Q/A on public fora
None.
## Next Meeting
2016-06-22
[TC39 Agenda]: https://github.com/tc39/agendas/blob/master/2016/07.md

151
doc/ctc-meetings/2016-06-22.md

@ -1,151 +0,0 @@
# Node Foundation CTC Meeting 2016-06-22
## Links
* **Audio Recording**: TBP
* **GitHub Issue**: https://github.com/nodejs/node/issues/7366
* **Minutes Google Doc**: <https://docs.google.com/document/d/1X9PTcpYgTKJO-PRKOLBrL4fIV-7XDR0x71FAxJWn0II>
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/1e7JdFHVtMtW9_o0Gi3NNz6g7TK50q4u9LYKFzBeHOQ8>_
## Present
* Bradley Meck @bmeck (observer/GoDaddy/TC39)
* Chris Dickinson @chrisdickinson (CTC)
* Evan Lucas @evanlucas (CTC)
* James M Snell @jasnell (CTC)
* John-David Dalton @jdalton (observer/Lodash/Microsoft)
* Yuval Brik @jhamhader (observer)
* Josh Gavant @joshgav (observer/Microsoft)
* Michael Dawson @mhdawson (CTC)
* Brian White @mscdex (CTC)
* Ali Ijaz Sheikh @ofrobots (CTC)
* 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
* Node 6 fs.realpath behavior changes [#7175](https://github.com/nodejs/node/issues/7175)
## Standup
* Bradley Meck @bmeck (observer/GoDaddy/TC39)
* Need for APM / JIT Cache hooks investigation
* Investigation into VM support for V8 and ES Modules
* Chris Dickinson @chrisdickinson (CTC)
* Keeping track of ES Modules proposals
* tooling gn to be npm installable
* Evan Lucas @evanlucas (CTC)
* working on security fixes
* looking for ways to streamline landing commits
* James M Snell @jasnell (CTC)
* Vacation last week (worked on an experimental http/2 impl)
* Working on WHATWG URL implementation
* Various other performance related and doc PRs
* And a heads up.. Will be on vacation again the 2nd and 3rd weeks of July.
* John-David Dalton @jdalton (observer/Lodash/Microsoft)
* Retooled proposal to simplify it and make it more generic so it will work with things other than just script and module
* Babel now supports export {} and therefore supports Unambiguous Modules proposal
* Pinged some v8 devs to ask about impact there
* Met with TypeScript folks too to discuss things that are a bit out of the scope of Unambiguous JavaScript but still modules
* Initial round of feedback on Unambiguous JavaScript. Will be in JavaScript Weekly tomorrow.
* Josh Gavant @joshgav (observer/Microsoft)
* hacking on inspector and tracing stuff
* es6 modules a bit
* monitoring issues, PRs, etc.
* Michael Dawson @mhdawson (CTC)
* Chasing PPC machine issues
* Chasing new AIX machines (expect this month)
* Contributing to ABI stable module API PoC (NaN examples 1-8 now work)
* Misc reviews/commenting
* misc PRs/lands
* Keeping up with issues
* Brian White @mscdex (CTC)
* Reviewing PRs/issues
* Shigeki Ohtsu @shigeki (CTC)
* Reviewing just one PR for root cert update.
* Steven R. Loomis @srl295 (observer/IBM/ICU)
* helping @jasnell (a little) with https://github.com/nodejs/node/pull/7355
* Trevor Norris @trevnorris (CTC)
* Additional work on the AsyncWrap EP
* Misc PR reviews
* Rich Trott @Trott (CTC)
* CO: Continuous Onboarding (welcome @RReverser!)
* CI: Investigating and fixing flaky tests as time allows
* Ali Ijaz Sheikh @ofrobots(CTC)
* Working on FFI, and other miscellaneous things.
## Minutes
### Review of last meeting
* 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)
* ES6 Modules
### fs.realpath
- https://github.com/nodejs/node/issues/7175
- https://github.com/nodejs/CTC/issues/9
- https://github.com/nodejs/node/issues/7192
- https://github.com/nodejs/node/issues/7044
- https://github.com/nodejs/node/issues/7294
When we made changes to rely on libuv realpath it was a semver-major change which introduced new errors and removed `cache` argument. This broke some ecosystem modules, notably `glob`. Also broke some path-related stuff in Windows.
We chose libuv realpath because it’s much more performant.
Options:
- Revert to old behavior. Would lose perf gains. Would be semver-major change.
- Add new method e.g. `realpath2` which uses old behavior.
- **Keep new behavior and add logic in Node to handle new/unexpected errors.**
@jasnell - We did a semver-major revert for the symlink issue.<br />
@trevnorris - No need to revert, just handle the errors.<br />
@jasnell - Do we really know what the errors are so we can be sure we’re handling all of them?<br />
@trevnorris - we can compare to old impl.<br />
@jasnell - Add an option to the options object to suppress errors, turn on by default.<br />
**@trevnorris will work on option 3.**
Post-mortem: https://github.com/nodejs/CTC/issues/9
- Postpone till Rod is present.
- @jasnell - We didn’t follow typical deprecation path for `cache` parameter change.
### ES6 modules
- https://github.com/bmeck/UnambiguousJavaScriptGrammar
- Any code with `import` or `export` is a module, otherwise a script.
- `modules.root` aspect removed, so “fat packages” (i.e. incl. both ES6 and CJS) are not addressed. Recommendation is to use one or the other and transpile as needed. Or discuss `modules.root` separately.
- Users can explicitly specify module goal in package.json. This way even if dev removes all `import/export` from their code it’s still treated as a module.
- TC39 could provide a “recommendation” or endorsement supporting this. They may suggest a spec extension.
@bradleymeck - still need modules.root for fat packages.
What about bytecode caching? Provide hooks to allow user to handle as desired. That means caching is in userland. Might split this into separate proposal.
@trevnorris analyzed perf hit of double parsing and found max 25% perf hit.
In-band detection (from the code itself) is preferable to out-of-band detections (e.g. package.json, file extension).
CJS and ES6 semantic interoperability: Bradley is working on this, working with WHATWG Loader spec and V8.
- `this` value
- live bindings for getters (get updated values) (?)
- immutability - hooks for APM providers to wrap original functions. To be handled by WHATWG Loader spec.
**@jdalton - How do we finalize consensus on this?**
- **PR to change [node-eps:/002-es6-modules.md](https://github.com/nodejs/node-eps/blob/master/002-es6-modules.md)**
### Q/A on public fora
None.
### Next Meeting
2016-06-29

187
doc/ctc-meetings/2016-06-29.md

@ -1,187 +0,0 @@
# Node Foundation CTC Meeting 2016-06-29
## Links
* **Audio Recording**: TBP
* **GitHub Issue**: https://github.com/nodejs/node/issues/7474
* **Minutes Google Doc**: <https://docs.google.com/document/d/1a19l2ICQHCw2w6cM4AayRM8QX8cIrgnHXCtzmuxfWuM>
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/1X9PTcpYgTKJO-PRKOLBrL4fIV-7XDR0x71FAxJWn0II>_
## Present
* Bradley Meck @bmeck (observer/GoDaddy/TC39)
* Сковорода Никита Андреевич @ChALkeR (CTC)
* Colin Ihrig @cjihrig (CTC)
* Evan Lucas @evanlucas (CTC)
* Jeremiah Senkpiel @Fishrock123 (CTC)
* James M Snell @jasnell (CTC)
* John-David Dalton @jdalton (observer/Lodash/Microsoft)
* Josh Gavant @joshgav (observer/Microsoft)
* Michael Dawson @mhdawson (CTC)
* Brian White @mscdex (CTC)
* Ali Ijaz Sheikh @ofrobots (CTC)
* Rod Vagg @rvagg (CTC)
* 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
* New Buffer API backport to v4.x [#7475](https://github.com/nodejs/node/pull/7475)
* child_process: validate fork/execFile arguments [#7399](https://github.com/nodejs/node/pull/7399)
* Node 6 fs.realpath behavior changes [#7175](https://github.com/nodejs/node/issues/7175)
* repl: Default `useGlobal` to false in CLI REPL. [#5703](https://github.com/nodejs/node/pull/5703)
* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979)
### nodejs/LTS
* Mention odd-number release has eight months support as Current. [#113](https://github.com/nodejs/LTS/issues/113)
### nodejs/node-eps
* AsyncWrap public API proposal [#18](https://github.com/nodejs/node-eps/pull/18)
## Standup
* Bradley Meck @bmeck (observer/GoDaddy/TC39)
* Trying to gather all stakeholders in ES Module implementations into a meeting
* Back and forth with V8 about details of CJS bridge
* John-David Dalton @jdalton (observer/Lodash/Microsoft)
* Dropped caching from unambiguous JS proposal
* PR to Node EPS repo
* Discussed with V8 (Adam Klein) and Chakra about adding the API, no blockers
* Сковорода Никита Андреевич @ChALkeR (CTC)
* Filed #7475 to backport new Buffer API to 4.x LTS
* Colin Ihrig @cjihrig (CTC)
* Reviewing issues and PRs. Made a couple libuv PRs.
* Evan Lucas @evanlucas (CTC)
* Merged pr to allow passing prompt to readline
* Merged pr that prints experimental warning when using inspector
* Worked on v6.x branch a little
* Jeremiah Senkpiel @Fishrock123 (CTC)
* Was away a bit adjusting to Europe.
* Misc PRs/Issues work.
* Also working to resolve https://github.com/nodejs/node/issues/5426 (ages old timers issue)
* Josh Gavant @joshgav (observer/Microsoft)
* Scheduled next Diag WG meeting (7/13 12 Pacific) (https://github.com/nodejs/diagnostics/issues/60)
* “Inspector Gateway” proposal (https://github.com/nodejs/node/issues/7393)
* Module discussions
* Michael Dawson @mhdawson (CTC)
* Testing problematic PPC machine after move to new node, adding back to regular CI runs
* Working on ABI stable API prototype with Ian/Sampson
* Post mortem work with Richard C
* Misc PR reviews/lands
* Adding linuxOne to master test jobs in CI (since 5.1 landed there)
* LTS, Build WG meetings
* Starting to work on presentations for upcoming conferences
* Brian White @mscdex (CTC)
* Landed a fix for a StringDecoder regression
* Reviewed PRs, commented on issues
* Ali Ijaz Sheikh @ofrobots (CTC)
* Busy with non-Node stuff mostly.
* Rod Vagg @rvagg (CTC)
* Chat with Electron team
* Foundation board meeting
* npm publish bug hunt
* node-gyp release, fix for latest MSVS 2015 release
* Steven R Loomis @srl295 (observer/IBM/ICU)
* regrets for this meeting- nothing to add at this point(hopefully soon)
* Trevor Norris @trevnorris (CTC)
* working on solution for user API for AsyncWrap (?)
* Rich Trott @Trott (CTC)
* child_process fixes
* examining https://node-core-coverage.addaleax.net/ results (thanks, @addaleax!)
* re-certifying flaky tests
## Minutes
### child_process: validate fork/execFile arguments [#7399](https://github.com/nodejs/node/pull/7399)
@trott: Semver-major change requires review.
@trott: fixing a bug that James filed some time ago - if nonsensical arguments are passed to these methods they silently ignore those arguments. Rich and James think it should throw if you give it garbage.
@nodejs/ctc: No objections.
### Node 6 fs.realpath behavior changes [#7175](https://github.com/nodejs/node/issues/7175)
@trevnorris was to work on capturing new errors and handling them. Discovered that all fs methods suffer same issue. Trevor has idea on how to handle it, will submit PR in the next day or two.
@bzoz understands Windows issues and will address them.
### buffer: backport --zero-fill-buffers command line option [#5745](https://github.com/nodejs/node/pull/5745)
See also [#7475](https://github.com/nodejs/node/pull/7475).
Backport to v4. Was discussed and CTC thought it wasn’t a good idea, but want to revisit now. What was previous issue? @Fishrock123 - another change, possibly security-related, blocked it.
@rvagg: Same objections as backport to 0.12, should be treated the same.
@nodejs/ctc: No objections currently. This is relevant to security.
### repl: Default `useGlobal` to false in CLI REPL. [#5703](https://github.com/nodejs/node/pull/5703)
* Some discussion in the original issue: https://github.com/nodejs/node/issues/5659#issuecomment-195543607
* Moving back to GitHub.
### Mention odd-number release has eight months support as Current. [lts#113](https://github.com/nodejs/LTS/issues/113)
* Current state is that Current (formerly Stable) branch is supported for **two** months after next release but some people think it’s **three** months. For example, v5 is supported till end of June 2016. But we’d like this to be stated clearly.
@mhdawson: discussion in last LTS meeting but it’s not in the scope of the LTS WG’s work so it’s up to the CTC. Is it Current+2 or Current+3?
@nodejs/ctc: Previous Current version is supported for two months after next version is released.
@rvagg: v5 is still heavily used.
@Fishrock123: npm metrics also show high usage of v5, not much decline.
Need to make clear that people need to upgrade. Should we push this harder or adjust to usage pattern?
@nodejs/ctc: Stick with plan to stop supporting v5 shortly.
Metrics: https://nodejs.org/metrics/summaries/version.png
### AsyncWrap public API proposal [node-eps#18](https://github.com/nodejs/node-eps/pull/18)
@Fishrock123 - responses have been primarily positive, time for CTC to consider.
@rvagg - Goal is to raise awareness amongst CTC today, vote on it next week.
@rvagg - currently marked as experimental. We should associate a message/warning with experimental API usage. EPs are for experimental APIs.
@trevnorris - AsyncWrap cannot track callbacks from native addons. Also investigating why sometimes messages are dropped (?).
### replace section 5.1 with unambiguous JavaScript grammar [node-eps#33](https://github.com/nodejs/node-eps/pull/33)
@jdalton wants to get agreement from Node.js CTC so that he can proceed to browser vendors.
TC39 may want to add other “goals” for files in addition to module and script such as asm.js, “frozen realms”.
@rvagg: If we go with `.mjs` we’d have to have extensions for new parse goals too...
@rvagg: We prefer a spec change in TC39/ES262 or an acknowledgement at least. @jdalton will add that caveat into the PR.
@Fishrock123: What about avoiding double parsing?
@bmeck: Chakra said maybe, V8 said probably not. @trevnorris did benchmarks and they weren’t too bad.
`module.root` for fat packages? With .mjs it wasn’t needed, people would include .js and .mjs files; but with new proposal it is needed. However `module.root` isn’t foolproof because people could use it for general redirection/hiding of package internals instead of only for ES6 modules.
@rvagg: Let’s slate for vote on Wednesday 7/6, those who are unavailable can vote in the issues.
## Q/A on public fora
None.
## Next Meeting
* AsyncWrap public API proposal [node-eps#18](https://github.com/nodejs/node-eps/pull/18)
* replace section 5.1 with unambiguous JavaScript grammar.
[node-eps#33](https://github.com/nodejs/node-eps/pull/33)
CTC: 2016-07-06

150
doc/ctc-meetings/2016-07-06.md

@ -1,150 +0,0 @@
# Node Foundation CTC Meeting 2016-07-06
## Links
* **Audio Recording**: TBP
* **GitHub Issue**: https://github.com/nodejs/node/issues/7558
* **Minutes Google Doc**: <https://docs.google.com/document/d/1NWIKwYxDTApvc9Xbq5JTMorRPKIBuBKAA0zcjm8K_II>
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/1a19l2ICQHCw2w6cM4AayRM8QX8cIrgnHXCtzmuxfWuM>_
## Present
* Сковорода Никита Андреевич @ChALkeR (CTC)
* Colin Ihrig @cjihrig (CTC)
* Evan Lucas @evanlucas (CTC)
* Jeremiah Senkpiel @Fishrock123 (CTC)
* James Snell @jasnell (CTC)
* John-David Dalton @jdalton (observer/Microsoft)
* Josh Gavant @joshgav (observer/Microsoft)
* Michael Dawson @mhdawson (CTC)
* Brian White @mscdex (CTC)
* Alexis Campailla @orangemocha (CTC)
* Shigeki Ohtsu @shigeki (CTC)
* Trevor Norris @trevnorris (CTC)
* Rich Trott @Trott (CTC)
## Standup
* Сковорода Никита Андреевич @ChALkeR (CTC)
* Nothing significant.
* Colin Ihrig @cjihrig (CTC)
* Reviewed issues. Reviewed pull requests. Opened a couple PRs
* Evan Lucas @evanlucas (CTC)
* Commented on a few issues, not much else
* Jeremiah Senkpiel @Fishrock123 (CTC)
* v6.3.0 Release, most difficult to date, lots of merge conflicts.
* Various PR / Issue review
* John-David Dalton @jdalton (observer/Microsoft)
* Another round of questions with Chakra dev about Unambiguous JS Grammar confirming difficulty level of API is not significant
* Updated Unambiguous JS Grammar based on feedback
* Josh Gavant @joshgav (observer/Microsoft)
* Out for July 4th holiday.
* Michael Dawson @mhdawson (CTC)
* Added linuxOne to regression tests/watched for issues, all looks good, next step is to add to nightly releases
* Chasing down AIX build breaks test failures
* Continued work on ABI stable module API and scheduling of next WG meeting
* misc PR/Issue reviews/pull requests
* post-mortem work and scheduling of next meeting
* small update to benchmark graphs
* keeping up to date with issues
* Brian White @mscdex (CTC)
* Started the process of rebasing the old js http parser onto master to see how it compares to the current http implementation
* Reviewed PRs, commented on issues
* Alexis Campailla @orangemocha (CTC)
* Nothing to report (was out on vacation)
* Shigeki Ohtsu @shigeki (CTC)
* Reviewed only one PR for crypto doc
* Trevor Norris @trevnorris (CTC)
* Updated AsyncWrap EP
* fs.realpath() deep symlink PR
* Rich Trott @Trott (CTC)
* Onboarded @bzoz
* Fixing test-net-write-slow on FreeBSD (PR #7555)
* James M Snell @jasnell (CTC)
* WHATWG http implementation
* Closing up other business before going on vacation for a week
## Agenda
Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting.
### nodejs/node
* build: drop support for VS 2013 in v7 [#7484](https://github.com/nodejs/node/issues/7484)
* Node 6 fs.realpath behavior changes [#7175](https://github.com/nodejs/node/issues/7175)
### nodejs/node-eps
* Replace section 5.1 with unambiguous JavaScript grammar. [#33](https://github.com/nodejs/node-eps/pull/33)
* AsyncWrap public API proposal [#18](https://github.com/nodejs/node-eps/pull/18)
## Previous Meeting
* New Buffer API backport to v4.x [#7475](https://github.com/nodejs/node/pull/7475)
* New PR: https://github.com/nodejs/node/pull/7562
* child_process: validate fork/execFile arguments [#7399](https://github.com/nodejs/node/pull/7399)
* Node 6 fs.realpath behavior changes [#7175](https://github.com/nodejs/node/issues/7175)
* repl: Default `useGlobal` to false in CLI REPL. [#5703](https://github.com/nodejs/node/pull/5703)
* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979)
* Mention odd-number release has eight months support as Current. [#113](https://github.com/nodejs/LTS/issues/113)
* AsyncWrap public API proposal [#18](https://github.com/nodejs/node-eps/pull/18)
## Minutes
### build: drop support for VS 2013 in v7 [#7484](https://github.com/nodejs/node/issues/7484) (@jasnell)
Consider v6 and v7 separately. All agree on moving to VS 2015 for v7. Only question is v6 prior to LTS. We need more info to make decision on v6.
If we stay with 2013 for v6 we’ll have to support it for the entire lifetime of v6 LTS. But it needs to still be possible to build native addons with 2013.
@jasnell - Our recommendation is to build native addons with VS 2015 unless it doesn’t work (e.g. in [node-sass#1283](https://github.com/sass/node-sass/issues/1283).
@orangemocha - No problem building `node.exe` with VS 2015 in v7. But dropping support for 2013 would break some modules (breaking change) due to ABI incompatibilities, so it might not be appropriate for v6. Need more time to assess impact.
### Node 6 fs.realpath behavior changes [#7175](https://github.com/nodejs/node/issues/7175)
@trevnorris - fix is working, test in development. Comment further in the PR.
### Replace section 5.1 with unambiguous JavaScript grammar. [#33](https://github.com/nodejs/node-eps/pull/33)
@jdalton added line stating explicitly that the .mjs proposal is still possible.
Vote taken in favor of merging this PR. Alexis officially abstained.
### AsyncWrap public API proposal [#18](https://github.com/nodejs/node-eps/pull/18)
See also [#7565](https://github.com/nodejs/node/issues/7565), which questions whether AsyncWrap should exist (from @bnoordhuis).
@jasnell - Error handling should be addressed.
@trott - A vote for the EP means “*if* we implement, this is what the JavaScript API will look like” and not necessarily “we intend to implement this.”
@trevnorris - Correct. Confirm the API, then more work is needed on implementation, e.g. to include info on promises.
@trevnorris - biggest missing chunk is public C++ API. Trouble is that it requires exposing some things which are not currently in public headers.
@trevnorris - Goal is to include this as experimental in v6 before LTS. But still waiting on additional hooks into promises from V8.
@Fishrock123 - AsyncWrap is best bet for CLS across async activities, replaces deprecated domains.
Vote: 7-8 ayes, 0 opposed, 0 abstentions.
## Q/A on public fora
None.
## Next Meeting
* Move to VS 2015 for release build in v6? Is this a breaking change?
## Upcoming TLP & WG Meetings
* CTC: 2016-07-13
* TSC: 2016-07-14
* Diagnostics: 2016-07-13
* Post-Mortem: [nodejs/post-mortem#31](https://github.com/nodejs/post-mortem/issues/31)
* LTS:
* Build:

236
doc/ctc-meetings/2016-07-13.md

@ -1,236 +0,0 @@
# Node Foundation CTC Meeting 2016-07-13
## Links
* **Audio Recording**: TBP
* **GitHub Issue**: https://github.com/nodejs/node/issues/7707
* [Minutes Google Doc](https://docs.google.com/document/d/1fP9_ZNcPoFh2VWCgUFu9-rDiDcMP88vhCC_oX6Aj528)
* _[Previous Minutes Google Doc](https://docs.google.com/document/d/1NWIKwYxDTApvc9Xbq5JTMorRPKIBuBKAA0zcjm8K_II)_
## Present
* Anna Henningsen @addaleax (observer)
* Bradley Meck @bmeck (observer/GoDaddy/TC39)
* Ben Noordhuis @bnoordhuis (CTC)
* Colin Ihrig @cjihrig (CTC)
* Evan Lucas @evanlucas (CTC)
* Jeremiah Senkpiel @Fishrock123 (CTC)
* Fedor Indutny @indutny (CTC)
* 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)
* Stephen Loomis @srl295 (observer/ICU)
* Myles Borins @TheAlphaNerd (observer)
* Trevor Norris @trevnorris (CTC)
* Rich Trott @Trott (CTC)
## Standup
* Anna Henningsen @addaleax (observer)
* PRs & issues
* Some v4.x backports
* Bradley Meck @bmeck (observer/GoDaddy/TC39)
* Bad news from V8/Chakra. Can’t do property hoisting for Babel like CJS interop.
* Figuring out hooks for creating Modules in older Node versions
* Ben Noordhuis @bnoordhuis (CTC)
* Back-porting patches
* Moving stuff over from malloc() to new[] because of AIX
* ABI compatibility tool
* PRs & issues, of course - how could I forget?
* Colin Ihrig @cjihrig (CTC)
* Reviewed issues and PRs
* Opened a few PRs
* Evan Lucas @evanlucas (CTC)
* Simple doc fix
* Working on cherry-picking into v6.x
* Jeremiah Senkpiel @Fishrock123 (CTC)
* Fixed a TTY test that was silently failing for over a year
* misc PR & issue work
* Fedor Indutny @indutny (CTC)
* Various GYP-related tooling
* Code reviews, and fixing issues
* Josh Gavant @joshgav (observer/Microsoft)
* Diagnostics WG meeting
* debugging docs
* Michael Dawson @mhdawson (CTC)
* Added LinuxOne to v8 tests in CI
* Involvement on some AIX issues
* Working on ABI stable API, API WG meeting this week
* Re-scheduled post-mortem WG meeting for next week, LTS and diagnostic WG meetings
* misc reviews/lands and keeping up on issues
* Brian White @mscdex (CTC)
* Worked on PR to check for accidental git conflict markers when linting in CI
* Backported some commits to v4.x
* Reviewed PRs and commented on issues
* Ali Ijaz Sheikh @ofrobots (CTC)
* Back from vacation, buried in email (sorry for late responses!)
* Alexis Campailla @orangemocha (CTC)
* Investigating ABI incompatibilities. Preparing to drop VS 2013.
* Reviewed miscellaneous Windows issues.
* Resumed work on a PR for case normalization of the module cache on Windows
* Rod Vagg @rvagg (CTC)
* LTS README rework
* Steven Loomis @srl295 (observer/ICU)
* not much here, just trying to keep an eye on issues/PRs
* Myles Borins @TheAlphaNerd (observer)
* Working on v4.5.0 release https://github.com/nodejs/node/pull/7688
* CITGM Enhancements (XML + Queue)
* Working with V8 team to improve workflow for managing floated commits https://github.com/nodejs/LTS/issues/111
* Trevor Norris @trevnorris (CTC)
* Working fix for one of the realpath bugs
* Backporting for v4.x
* Working on AsyncWrap implementation details
* Rich Trott @Trott (CTC)
* Trying to handle flaky test outbreak on FreeBSD in CI
* Various ESLint updates/improvements
* Banging my head against test-tick-processor flakiness which is easily the longest-standing flaky test.
## Agenda
Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting.
### nodejs/node
* build: drop support for VS 2013 in v7 [#7484](https://github.com/nodejs/node/pull/7484)
* Node 6 fs.realpath behavior changes [#7175](https://github.com/nodejs/node/pull/7175)
* http: don't inherit from Object.prototype [#6102](https://github.com/nodejs/node/pull/6102)
* v4.5.0 proposal [#7688](https://github.com/nodejs/node/pull/7688)
### nodejs/node-eps
* proposal: WHATWG URL standard implementation [#28](https://github.com/nodejs/node-eps/pull/28)
## Previous Meeting
### build: drop support for VS 2013 in v7 [#7484](https://github.com/nodejs/node/issues/7484) (@jasnell)
To be discussed again.
### Node 6 fs.realpath behavior changes [#7175](https://github.com/nodejs/node/issues/7175)
@trevnorris was to complete changes, to be discussed again.
### Replace section 5.1 with unambiguous JavaScript grammar. [#33](https://github.com/nodejs/node-eps/pull/33)
@jdalton’s proposal was merged.
### AsyncWrap public API proposal [#18](https://github.com/nodejs/node-eps/pull/18)
API was accepted, implementation TBD before October.
## Minutes
### build: drop support for VS 2013 in v7 [#7484](https://github.com/nodejs/node/issues/7484)
@orangemocha: Decision to drop in v7 isn’t controversial. Will need to add tests for modules compiled with 2013 used with Node compiled with 2015.
@orangemocha: Main question is switching in v6 before LTS. Is it a breaking change?
Issue with node-sass module only comes up on Windows XP so can be discounted.
No way to be sure if user modules compiled with 2013 might be incompatible with Node compiled with 2015. Have to run tests. Will CITGM provide sufficient testing?
@myles: may not be enough native modules in CITGM to provide confidence.
@Fishrock123: be sure to also test on pre-gyp’ed modules.
@orangemocha: we may never have complete confidence that this isn’t a breaking change, but node-sass is the only issue ever reported.
@orangemocha: Should we support modules built with 2013 in v7?
@rvagg: need to include that in tests.
**Next steps**: Run tests with modules compiled with 2013 to see if there are issues. Keep on agenda for next week and check on progress.
### Node 6 fs.realpath behavior changes [#7175](https://github.com/nodejs/node/pull/7175)
* ELOOP fix: https://github.com/nodejs/node/pull/7548
* Windows PR: https://github.com/nodejs/node/pull/7559 (see also https://github.com/nodejs/node/issues/7192)
ELOOP issue has been resolved. Windows problem being addressed in another PR. May have to use JS impl for Windows.
@rvagg: If libuv can’t handle the realpath issue for Windows what should we do?
@orangemocha: We’re using the JS impl for Windows.
@trevnorris: we can use the libuv impl and defer to the JS impl if the libuv impl throws unexpectedly.
@rvagg: should we just revert? How common is the case where this provides a speed-up?
@trevnorris: keep both libuv and js impl for now.
**Next steps**: All please review #7548 and #7559.
### http: don't inherit from Object.prototype [#6102](https://github.com/nodejs/node/pull/6102)
@mscdex: Prevent clash of header names with properties inherited from Object (e.g., `__proto__`). An object with a null prototype is already being used for the same purpose in `querystring.parse` since v6 release.
@mscdex: Some have suggested cherry-picking some methods from Object such as `toString`:
* So that object can be inspected.
* To ensure backward compatibility.
@mscdex: An eventual goal may be to store headers in an ES6 Map instead of on a plain object, but that will change the API considerably.
@evanlucas: we should follow what we did with query string parameters.
@rvagg: first need to review as some opposition to that.
**Next steps**: All review PR.
### proposal: WHATWG URL standard implementation [node-eps#28](https://github.com/nodejs/node-eps/pull/28)
@trevnorris: Some discussion about supporting unregistered schemes (e.g. `chrome://`). We should support them, Chrome supports them.
@trevnorris: `url.parse` can handle incomplete URLs (e.g. no scheme).
@rvagg: Most important question is should `URL` be a global? There would be a `url` module and a different `URL` global.
@fishrock123: there would be a transition period and then functionality would be in `URL`
@rvagg: new impl is quite different from existing `url` module. Would like to see a diff. Migration will be difficult.
**Next steps**: Waiting for @jasnell to return. Review again next week.
### v4.5.0 proposal [#7688](https://github.com/nodejs/node/pull/7688)
@thealphanerd:
* Would like to include libuv v1.9.1.
* Would like very extensive testing prior to release to exclude breaking changes.
How can we best test?
@rvagg: Promote the RC on social media.
@thealphanerd: npm could help test, Myles will reach out.
@rvagg: Heroku? (Hunter Loftis) Travis CI? Probably not because it depends on nvm which doesn’t do RC’s yet.
@thealphanerd: will talk with @ljharb about nvm support for RCs.
**Next steps**: @thealphanerd will ping all to test RC.
### ES Modules update
@bmeck: named imports from CJS modules (e.g. `import {use, route} from "express"` or `import {readFile, readFileSync} from "fs"`) can’t work.
Updates to come on the topic via: https://github.com/nodejs/node-eps/issues/26
## Q/A on public fora
## Upcoming Meetings
* CTC: 2016-07-20
* TSC: 2016-07-14
* Diagnostics: 2016-08-03
* Post-Mortem: 2016-07-18
* API: 2016-07-14
* LTS: 2016-07-25
* Build: 2016-07-19

202
doc/ctc-meetings/2016-07-20.md

@ -1,202 +0,0 @@
# Node Foundation CTC Meeting 2016-07-20
## Links
* **Audio Recording**: TBP
* **GitHub Issue**: https://github.com/nodejs/node/issues/7809
* **Minutes Google Doc**: <https://docs.google.com/document/d/1Gr1XX-DuzgGXON5uAzrZHjWwXoQ4AIJEAJ2DK5jNmp4>
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/1fP9_ZNcPoFh2VWCgUFu9-rDiDcMP88vhCC_oX6Aj528>_
## Present
* Anna Henningsen @addaleax (observer)
* Ben Noordhuis @bnoordhuis (CTC)
* Сковорода Никита Андреевич @ChALkeR (CTC)
* Colin Ihrig @cjihrig (CTC)
* Evan Lucas @evanlucas (CTC)
* Jeremiah Senkpiel @Fishrock123 (CTC)
* Josh Gavant @joshgav (observer/Microsoft)
* Michael Dawson @mhdawson (CTC)
* Julien Gilli @misterdjules (CTC)
* Brian White @mscdex (CTC)
* Ali Ijaz Sheikh @ofrobots (CTC)
* Alexis Campailla @orangemocha (CTC)
* Rod Vagg @rvagg (CTC)
* Seth Thompson @s3ththompson (observer/Google)
* Shigeki Ohtsu @shigeki (CTC)
* Steven R Loomis @srl295 (observer/IBM/ICU)
* Myles Borins @TheAlphaNerd (observer)
* Trevor Norris @trevnorris (CTC)
* Rich Trott @Trott (CTC)
## Standup
* Anna Henningsen @addaleax (observer)
* Issues & PRs
* looking into porting JS-based realpath to C
* Ben Noordhuis @bnoordhuis (CTC)
* The usual (PR review and comment)
* Updating code base to do less manual memory management. PR coming soon.
* Сковорода Никита Андреевич @ChALkeR (CTC)
* Some initial work on docs linting.
* Some comments on issues and PRs.
* Colin Ihrig @cjihrig (CTC)
* Reviewed issues and PRs
* Opened PRs
* Evan Lucas @evanlucas (CTC)
* working on v6.3.1 release
* working on repl bugfix
* Jeremiah Senkpiel @Fishrock123 (CTC)
* Did some timers review for https://github.com/nodejs/node/commit/5aac4c42da104c30d8f701f1042d61c2f06b7e6c
* Clearing out some other old stuff I’ve assigned myself to
* Josh Gavant @joshgav (observer/Microsoft)
* Internal Microsoft work.
* Michael Dawson @mhdawson (CTC)
* Misc issues with PPC machines, added new PPC
machines from newer openstack
* Working with Ian/Sampson on ABI stable abi, status
update at API WG meeting
* Working with Richard/Howard on post-mortem activities,
post-mortem WG meeting this week.
* Misc reviews/lands
* Reading/keeping up/commenting on issues
* Getting ready for Node Summit talk.
* Julien Gilli @misterdjules (CTC)
* Looking forward to getting more involved again
* Investigating timers bug. Looking for someone to mentor on it
* Reviewing and commenting on pull requests
* Brian White @mscdex (CTC)
* Diving deep into reworking API docs
* Reviewing PRs, commenting on issues
* Ali Ijaz Sheikh @ofrobots (CTC)
* shepherding some V8 backports, v8_inspector license issue and roll
* Alexis Campailla @orangemocha (CTC)
* Nothing to report.
* Rod Vagg @rvagg (CTC)
* Usual administrative stuff, some build maintenance
* Seth Thompson @s3ththompson (observer/Google)
* Setting priorities for the next quarter.
* Team is continuing work on v8_inspector.
* Migrating v8_inspector into V8 itself.
* Shigeki Ohtsu @shigeki (CTC)
* Nothing special. Working internal jobs.
* Steven R Loomis @srl295 (observer/IBM/ICU)
* Nodesummit prep…
* Myles Borins @TheAlphaNerd (observer)
* v4.5.0-rc.2 released
* Email sent to npm team
* Trevor Norris @trevnorris (CTC)
* realpath fix
* Rich Trott @Trott (CTC)
* CTC governance doc updates
* onboarded @andrasq, will set up something with @princejwesley next, open to other nominations for after that
* eliminating more flaky tests (IT NEVER ENDS!!!!11!!!)
## Agenda
Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting.
### nodejs/node
* [meta] realpath issues in v6 [#7726](https://github.com/nodejs/node/issues/7726)
* v4.5.0 proposal [#7688](https://github.com/nodejs/node/pull/7688)
* http: don't inherit from Object.prototype [#6102](https://github.com/nodejs/node/pull/6102)
### nodejs/node-eps
* proposal: WHATWG URL standard implementation [#28](https://github.com/nodejs/node-eps/pull/28)
## Previous Meeting
* build: drop support for VS 2013 in v7 [#7484](https://github.com/nodejs/node/pull/7484)
* Node 6 fs.realpath behavior changes [#7175](https://github.com/nodejs/node/pull/7175)
* http: don't inherit from Object.prototype [#6102](https://github.com/nodejs/node/pull/6102)
* v4.5.0 proposal [#7688](https://github.com/nodejs/node/pull/7688)
* proposal: WHATWG URL standard implementation [#28](https://github.com/nodejs/node-eps/pull/28)
## Minutes
### [meta] realpath issues in v6 [#7726](https://github.com/nodejs/node/issues/7726)
@rvagg: some discussion of reversion to v5 behavior, i.e. JS implementation rather than libuv implementation.
@trevnorris: looks like everybody’s leaning towards a full revert (or at least a partial revert). I don’t like this plan but will go along.
@addaleax: Unfortunate to have to do full revert for *nix systems. But having alternate impl for Windows increases maintenance costs.
As part of the new implementation, the `cache` parameter was removed from the method. It was created to improve perf for the JS impl but is considered less necessary since the native impl performs better anyway.
Should we reinstate the `cache` parameter as part of the revert? Would this be a semver-major again? Does caching in the JS impl provide a significant perf benefit?
@addaleax: Benchmarking fs perf will show how much benefit the caching capability in libuv provides.
@mhdawson: we run two benchmarks nightly: one with caching and one without.
@orangemocha: It seems okay to have two impl’s, one for Windows and one for *nix, increased maintenance surface isn’t a concern, libuv manages libuv impl.
@rvagg: As we move v6 to LTS it would be best to have a known-good implementation. So would prefer a full revert, then fix libuv impl independently, then re-integrate.
@thealphanerd: Could we provide both interfaces? Revert the primary one to original behavior and add a second one with libuv behavior?
@rvagg: Still doesn’t address breaking change in Windows.
@fishrock123: also in favor of reverting. This has been going on for a long time, best to revert and then fix.
@orangemocha: should not compromise correctness for performance.
@trevnorris: caching could be separated from fs API. For example, it could be part of `module` module.
@rvagg: This is why I’m in favor of a full reversion. These other discussions may continue for a month and we need to correct problem now.
@thealphanerd: do we have a list of the original bugs the libuv patch addressed?
@saghul has a list.
@rvagg: back to github for now.
**Next steps**: continue discussion in GH.
### v4.5.0 proposal [#7688](https://github.com/nodejs/node/pull/7688)
@thealphanerd is raising visibility for tests and feedback.
@misterdjules may have some testers.
### http: don't inherit from Object.prototype [#6102](https://github.com/nodejs/node/pull/6102)
@rvagg: Need choices to vote on.
@ofrobots: Wants to explore more options including `map` so wait for vote. If the goal is to go to a map why don’t we do that now?
@Fishrock123: Because community has taken dependencies on it being an object.
@ofrobots: headers end up with “megamorphic IC’s” so wants to research further.
@Fishrock123: We are fixing this because header names like `__proto__` conflict with default object properties.
We should really just make an API for headers.
@rvagg: We’ll come back to this next week. Prepare wording for vote if ready.
**Next steps**: List available options and conduct vote next week.
## Q/A on public fora
None.
## Upcoming Meetings
* CTC: 2016-07-27
* TSC: 2016-07-28
* Build: 2016-08-07
* LTS: 2016-07-25
* Diagnostics: 2016-08-03
* Post-Mortem: August
* API: August

237
doc/ctc-meetings/2016-07-27.md

@ -1,237 +0,0 @@
# Node Foundation CTC Meeting 2016-07-27
## Links
* **Audio Recording**: https://www.youtube.com/watch?v=QAufnqo4ElY
* **GitHub Issue**: https://github.com/nodejs/node/issues/7881
* **Minutes Google Doc**: <https://docs.google.com/document/d/1rHxRb-ImjwFPOCOapgRDLdhqr4LJvie7eDNPOnDu2UA>
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/1Gr1XX-DuzgGXON5uAzrZHjWwXoQ4AIJEAJ2DK5jNmp4>_
## Present
* Anna Henningsen @addaleax (observer)
* Сковорода Никита Андреевич @ChALkeR (CTC)
* Jeremiah Senkpiel @Fishrock123 (CTC)
* Fedor Indutny @indutny (CTC)
* James M Snell @jasnell (CTC)
* Julien Gilli @misterdjules (CTC)
* Mikeal Rogers @mikeal (observer/Node.js Foundation)
* Brian White @mscdex (CTC)
* Alexis Campailla @orangemocha (CTC)
* Rod Vagg @rvagg (CTC)
* Steven R Loomis @srl295 (observer/IBM/ICU)
* Trevor Norris @trevnorris (CTC)
* Rich Trott @Trott (CTC)
* William Kapke @williamkapke (observer)
## Standup
* Anna Henningsen @addaleax (observer)
* Issues & PRs
* Some realpath work
* Сковорода Никита Андреевич @ChALkeR (CTC)
* Mostly comments and reviews, nothing significant
* Fedor Indutny @indutny (CTC)
* Issues, PRs, Direct-to-BIO experiments
* James M Snell @jasnell (CTC)
* Glorious vacation …
* Catching up
* Small clarification PR for IRC moderation
* Julien Gilli @misterdjules (CTC)
* PR reviews, especially https://github.com/nodejs/node/pull/7827, which looks like a very solid first contribution from a new contributor.
* Brian White @mscdex (CTC)
* Continued reworking of API docs
* Reviewed PRs, commented on issues
* Alexis Campailla @orangemocha (CTC)
* Investigating issues related to fs.realPath
* Investigating binary compatibility between Node and native modules compiled with different VS versions
* Working with team on various Windows issues in Node and libuv
* Rod Vagg @rvagg (CTC)
* NodeSummit / travel, Node v5 blog post nearly ready to post, bug in require() (still need to post in nodejs/node)
* Steven R Loomis @srl295 (observer/IBM/ICU)
* @ NodeSummit / prep… thinking about how to keep an eye on upcoming v8 changes. Did some more work on https://github.com/nodejs/node/issues/3460 (detect full-icu module).
* Trevor Norris @trevnorris (CTC)
* NodeSummit talk
* fs.realpath()
* Prepping AsyncWrap, target end of August
* Rich Trott @Trott (CTC)
* Updating governance text and whatnot
* Flaky tests
* NodeSummit talk
* William Kapke @williamkapke (Observer)
## Agenda
Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting.
### nodejs/node
* Role of CTC in semver-major changes needs clarification [#7848](https://github.com/nodejs/node/issues/7848)
* Revert fs changes [#7846](https://github.com/nodejs/node/pull/7846)
* doc: add information about CTC quorum rules [#7813](https://github.com/nodejs/node/pull/7813)
* meta: provide example activities [#7744](https://github.com/nodejs/node/pull/7744)
* meta: realpath issues in v6 [#7726](https://github.com/nodejs/node/issues/7726)
* v4.5.0 proposal [#7688](https://github.com/nodejs/node/pull/7688)
* punycode: deprecate punycode module [#7552](https://github.com/nodejs/node/pull/7552)
* Node 6 fs.realpath behavior changes [#7175](https://github.com/nodejs/node/issues/7175)
* http: don't inherit from Object.prototype [#6102](https://github.com/nodejs/node/pull/6102)
* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979)
### nodejs/post-mortem
* Repositories to contribute collaboratively [#30](https://github.com/nodejs/post-mortem/issues/30)
### nodejs/node-eps
* proposal: WHATWG URL standard implementation [#28](https://github.com/nodejs/node-eps/pull/28)
## Previous Meeting
### nodejs/node
* [meta] realpath issues in v6 [#7726](https://github.com/nodejs/node/issues/7726)
* v4.5.0 proposal [#7688](https://github.com/nodejs/node/pull/7688)
* http: don't inherit from Object.prototype [#6102](https://github.com/nodejs/node/pull/6102)
### nodejs/node-eps
* proposal: WHATWG URL standard implementation [#28](https://github.com/nodejs/node-eps/pull/28)
## Minutes
### Role of CTC in semver-major changes needs clarification [#7848](https://github.com/nodejs/node/issues/7848)
### Revert fs changes [#7846](https://github.com/nodejs/node/pull/7846)
James: has to do with recent changes - making callback mandatory on all async functions apparently _broke the planet_, quite a few modules broke including a number used by npm, so `npm set` failed to work for example.
James: technically this should be viewed as a bugfix but we’ve already treated things involving errors as sensitive but this is on master and things a broken right now so suggesting that we revert this. Some alternatives are: not revert and get fixes in the ecosystem, revert and add warning.
Rich: Myles endorsed [#7897](https://github.com/nodejs/node/pull/7897) as a better alternative to reverting as it includes a warning. What’s the preferred approach here James?
James: revert, even though I don’t like it, we should revert and revisit.
Trevor: the fact that it was allowed was a bad decision because throwing can lead to hard-to-debug situations. Reverting is the _only course of action_.
Rod: wanted to clarify as a matter of culture - we should fix master as soon as we’re aware of breakage in the ecosystem and deal with things more cleanly as we can.
Julien: multiple commits in the revert PR, we should have separate discussions about them.
James: will ask on the PR that they be split into two.
James: second question here is whether we want to emit a warning instead?
Rod: the graceful-fs warnings are still widespread because lots of packages rely on very old versions and it’s taking a long time to get updates through the ecosystem. We have to be careful about (1) warning fatigue, (2) users not understanding the subtlety and interpreting warnings as errors. Would be good if we go a bit slower on moving to warnings.
James: we could run with warnings off by default as a way of dealing warning fatigue but that’s another discussion we can have on GitHub.
Rich: moving on, this can be done on Github.
### doc: add information about CTC quorum rules [#7813](https://github.com/nodejs/node/pull/7813)
Rich: there was a counter-proposal which seemed to be better so I updated to use Chalker’s alternative wording. **If anyone doesn’t want this to land please comment on it within the next 24 hours or so**. There hasn’t been too much discussion or disagreement.
### meta: provide example activities [#7744](https://github.com/nodejs/node/pull/7744)
Rich: Similar to the previous issue - have not got a whole lot of response, or a luke-warm response at least. Please comment in there if you have any problems with it, there are no negatives so it’ll land in the next 24 hours or so so please comment!
### \[meta\] realpath issues in v6 [#7726](https://github.com/nodejs/node/issues/7726)
Trevor: ran some benchmarks in CI to see how much time it would take to require() with and without cache in realpath. Haven’t done Windows but on the others there was between 10% to 100%, which is between 30us to 300us difference per require().
Alexis: [#7899](https://github.com/nodejs/node/pull/7899) reverts and also includes Myles’ reversions from the other fs issues.
Trevor: probably should revert and leave cache out, we might take a small hit now in perf but will lead to greater potential in the future.
Alexis: the cache was never a great API in the first place anyway.
Trevor: propose we revert and leave the cache and introduce a better fix.
Anna: agree with Trevor and Alexis.
Rod: should we get benchmarks on Windows?
Alexis: much more concerned about correctness than performance.
Trevor: this is a short-term fix, so we shouldn’t have a problem bringing it in.
Rich asked for disagreement with moving forward with reversion without cache? No disagreement. Need to comment on 7899, review & lgtm. Anna, Trevor or Alexis will move it forward.
### v4.5.0 proposal [#7688](https://github.com/nodejs/node/pull/7688)
James: because this adds some semver-minor’s Myles is very concerned about stability.
Julien: any ideas on how we might be able to get more testers for these?
James: maybe in a week, will get some suggestions posted to the LTS repo that we can discuss.
### punycode: deprecate punycode module [#7552](https://github.com/nodejs/node/pull/7552)
James: this is a 3rd party dependency that we expose and there’s some fairly extensive usage out there but there is a newer version out there in npm that people should be using.
Rich: no more comments? Please post on the repo.
Rod: deprecation is fine but would really like a long deprecation cycle.
James: how about soft deprecation in v7 and hard in v8?
Rod: soft in v7 and revisit decision to hard prior to v8.
Brian: if people build without ICU what would happen to punycode since we need it?
James: This particular PR introduces a hard deprecation that moves it to internal/ and has a shim that exposes it, so we could still use it internally but just deprecate the external API.
Brian: are we going to continue updating the non-ICU version for people going forward or just leave it?
James: would prefer to just leave it as is.
Chalker: on npm it has 5.7M downloads per month so people are already using it.
James: clarify: soft deprecate now and revisit hard deprecation prior to v8?
### http: don't inherit from Object.prototype [#6102](https://github.com/nodejs/node/pull/6102)
Rod: wanted to mention that Chris Dickinson expressed concerns on Twitter about us doing this same thing on querystring and that it was causing problems for him and didn’t like that it crept in to v6.
James: Doug, from the express side, thinks this is a good decision and cleans up things for users. The querystring thing has
… discussion tended towards accepting the change but CTC would like to solicit input from Chris Dickinson before getting it landed since he had raised some objections
### Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979)
Mikeal Rogers: discussing the SPDX stuff and restoration of licenses in the files. Mikeal and Rod will take the lead on moving forward with this.
### Repositories to contribute collaboratively [post-mortem#30](https://github.com/nodejs/post-mortem/issues/30)
Move to TSC meeting
### proposal: WHATWG URL standard implementation [node-eps#28](https://github.com/nodejs/node-eps/pull/28)
James: Passing WHATWG tests except some intentional ones. Performance is slower than our own url impl because of tests we fail. Any objections to moving forward?
Rod: we’re going to have two implementations, this seems like a difficult thing to agree on.
James: would like to eventually deprecate existing url.parse.
Rich: let’s move on because this will be a big conversation. Let’s have a brief conversation next week and slot a bigger discussion next week.
## Q/A on public fora
No questions.
## Upcoming Meetings
* CTC: 2016-08-03
* TSC: 2016-07-28
* Build: 2016-08-09
* Diagnostics: 2016-08-03
* Post-Mortem: August
* API: August

336
doc/ctc-meetings/2016-08-03.md

@ -1,336 +0,0 @@
# Node Foundation CTC Meeting 2016-08-03
## Links
* **Audio Recording**: TBP
* **GitHub Issue**: https://github.com/nodejs/node/issues/7948
* **Minutes Google Doc**: <https://docs.google.com/document/d/1ufR5dNuN3JLmFPvCvLYGRa98_-eqy5yY3zJuTnT60K8/edit#heading=h.ncvpl89y747j>
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/1rHxRb-ImjwFPOCOapgRDLdhqr4LJvie7eDNPOnDu2UA>_
## Present
* Anna Henningsen @addaleax (observer)
* Bradley Meck @bmeck (observer/GoDaddy/TC39)
* Ben Noordhuis @bnoordhuis (CTC)
* Сковорода Никита Андреевич @ChALkeR (CTC)
* Colin Ihrig @cjihrig (CTC)
* Evan Lucas @evanlucas (CTC)
* Jeremiah Senkpiel @Fishrock123 (CTC)
* James M Snell @jasnell (CTC)
* Josh Gavant @joshgav (observer/Microsoft)
* Michael Dawson @mhdawson (CTC)
* Brian White @mscdex (CTC)
* Ali Ijaz Sheikh @ofrobots (CTC)
* Bert Belder @piscisaureus (CTC)
* Saúl Ibarra Corretgé @saghul (observer)
* Rich Trott @Trott (CTC)
## Standup
* Anna Henningsen @addaleax (observer)
* Issues & PR review
* Bradley Meck @bmeck (observer/GoDaddy/TC39)
* Went to TC39
* Modules are going to take a different direction
* Ben Noordhuis @bnoordhuis (CTC)
* Nothing special.
* Сковорода Никита Андреевич @ChALkeR (CTC)
* Working on the npm dataset rebuilding tool. Some comments on issues and PRs as usual.
* Colin Ihrig @cjihrig (CTC)
* Was on vacation
* Reviewing issues and PRs since I've been back
* Evan Lucas @evanlucas (CTC)
* A little cherry-picking to v6.x
* Working on getting commit validator running for PRs
* Jeremiah Senkpiel @Fishrock123 (CTC)
* Mostly away, experimenting with nucleus-js.
* James M Snell @jasnell (CTC)
* Node Summit
* Exploring the possibility of an HTTP/2 implementation in core
* Continued evaluation of the WHATWG URL implementation
* Foundation-y / TSC-y stuff
* Reviewing PRs, catching up still from vacation
* Josh Gavant @joshgav (observer/Microsoft)
* internal stuff, vacation
* Michael Dawson @mhdawson (CTC)
* Node Summit/catching up on issues after Node Summit
* Starting to add linuxOne release machine/jobs
* Adding new AIX machine from osuosl
* landed a few minutes PRs
* Brian White @mscdex (CTC)
* Commenting on issues/PRs.
* Ali Ijaz Sheikh @ofrobots (CTC)
* Node Summit & internal stuff. Spent rest of time shepherding some backports.
* Planning on writing a proposal for managing V8 for LTS
* Bert Belder @piscisaureus (CTC)
* Commented on an issue.
* Rich Trott @Trott (CTC)
* CTC/governance documentation updates
* Onboarding (danbev postponed but we’ll get there, now scheduling with fhinkel, additional nominees welcome)
* fixed a flaky test, investigating others
## Agenda
Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting.
### nodejs/node
* CTC membership nomination: @addaleax [#7607](https://github.com/nodejs/node/issues/7607)
* Revert fs changes [#7846](https://github.com/nodejs/node/pull/7846)
* [meta] realpath issues in v6 [#7726](https://github.com/nodejs/node/issues/7726)
* v4.5.0 proposal [#7688](https://github.com/nodejs/node/pull/7688)
* build: drop support for VS 2013 in v7 [#7484](https://github.com/nodejs/node/issues/7484)
* http: don't inherit from Object.prototype [#6102](https://github.com/nodejs/node/pull/6102)
### nodejs/node-eps
* proposal: WHATWG URL standard implementation [#28](https://github.com/nodejs/node-eps/pull/28)
### other
* doc: @piscisaureus has stepped-down from the CTC [#7969](https://github.com/nodejs/node/pull/7969)
## Previous Meeting
### nodejs/node
* Role of CTC in semver-major changes needs clarification [#7848](https://github.com/nodejs/node/issues/7848)
* Revert fs changes [#7846](https://github.com/nodejs/node/pull/7846)
* doc: add information about CTC quorum rules [#7813](https://github.com/nodejs/node/pull/7813)
* meta: provide example activities [#7744](https://github.com/nodejs/node/pull/7744)
* meta: realpath issues in v6 [#7726](https://github.com/nodejs/node/issues/7726)
* v4.5.0 proposal [#7688](https://github.com/nodejs/node/pull/7688)
* punycode: deprecate punycode module [#7552](https://github.com/nodejs/node/pull/7552)
* Node 6 fs.realpath behavior changes [#7175](https://github.com/nodejs/node/issues/7175)
* http: don't inherit from Object.prototype [#6102](https://github.com/nodejs/node/pull/6102)
* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979)
### nodejs/post-mortem
* Repositories to contribute collaboratively [#30](https://github.com/nodejs/post-mortem/issues/30)
### nodejs/node-eps
* proposal: WHATWG URL standard implementation [#28](https://github.com/nodejs/node-eps/pull/28)
## Minutes
### CTC membership nomination: @addaleax [#7607](https://github.com/nodejs/node/issues/7607)
Unanimous `aye`.
**Next steps**: @rvagg to merge.
---
### Revert fs changes [#7846](https://github.com/nodejs/node/pull/7846)
Reverts:
https://github.com/nodejs/node/pull/7846
https://github.com/nodejs/node/pull/7950
Warn instead of throw when callback is omitted, as in v5:
https://github.com/nodejs/node/pull/7897
@bnoordhuis: This change makes omitting the callback an immediate error.
@trott: What do we need to do to get those PRs to land?
@addaleax: Myles split off one commit to [#7950](https://github.com/nodejs/node/pull/7950). Not controversial, was requested by CTC last week.
This must be landed prior to #7846.
@jasnell: Would like to see a CI and CITGM run and some additional testing to make sure we have exactly the right set of reverts. @jasnell will start it.
@bnoordhuis: We need to print a deprecation warning [instead of throwing, when no callback].
@addaleax: That’s the plan after the reverts have landed. @thefourtheye plans to work on it. [see #7897])
@jasnell: process warning or deprecation warning? Will we use `util.printDeprecationWarning` or `process.emitWarning()`?
Deprecation warning is semver-major, process warning is semver-minor or even patch.
[It's `printDeprecationWarning`, see [here](https://github.com/thefourtheye/io.js/blob/8c65f7b6a253ab4e26ffe0de791dc41fcee92244/lib/fs.js#L48).]
@addaleax: PR to print warning already opened. Could be used instead of reverting, but we agreed to revert last week and it blocks the realpath revert.
@Fishrock123: Unbreaking a break and replacing with warning shouldn’t be semver-major.
@trott: @jasnell’s PR on semver policies says it should be semver-major.
@Fishrock123: Since we already changed it in the v6 transition let’s just change it to a deprecation.
@trott: Let’s do the reverts (#7846, #7950), discuss deprecation warning separately in GH (#7897).
OK with everybody.
**Next steps**: Do the reverts (#7846, #7950). Continue discussion on throw -> warning in #7897.
---
### [meta] realpath issues in v6 [#7726](https://github.com/nodejs/node/issues/7726)
@trott: Last week we concluded that Anna, Trevor, or Alexis would move it forward.
@trott: Just the two reverts that are blocking.
@addaleax: Yes.
@saghul: Old JS impl did not resolve subst’ed drives. New libuv impl does. A test looks for the new behavior. ]
@saghul: Some people are relying on the old JS impl behavior to shorten paths on Windows. What are the right semantics? Should `subst`ed drives resolve to original path or to shortened path?
@piscisaureus: The whole reason we use realpath in `module` is to avoid a module being loaded multiple times via multiple symlinked paths. So the goal should be to always resolve to the true path.
@piscisaureus: Path limit is 64k not likely to encounter.
@saghul: There’s a test for the new code which expects realpath on a subst’ed drive to give the original path. We need to revert this test for reverted behavior.
@addaleax: Reverting to fs JS impl would return to old behavior.
@trott: Submit a PR to remove that test, or move to known issues tests.
@piscisaureus: Leave the test to track changes in the future.
@Fishrock123: Key is to revert to an impl the ecosystem is depending on. Discuss this in another PR in GitHub.
@jasnell: It’s a revert of the internal impl, not the changed public API [i.e. so we have to consider it now.]
What about reverting the removal of the `cache` option?
@addaleax: Not including the `cache` option now would allow additional/alternate improvements in the future.
@bnoordhuis: Are these changes to land in v7?
@jasnell: The idea is to get these into *v6* before it goes LTS.
* The realpath change would land in v6.
* The other changes (revert throwing error on callback) is only in master and would not land in v6.
* Are the realpath changes dependent on the others?
* Only Myles’ changes conflict with realpath [see previous item].
@jasnell: Do we have the steps lined up?
@addaleax: Myles revert (#7846, #7950), then realpath revert.
@? apply semver-major changes that were reverted, with deprecation warning.
@chalker: Can we keep tests which were added? Revert removes some tests which aren’t actually related to changes.
@piscisareus: Same as @saghul’s comment, and we agreed to keep the new tests. So yes we should keep them.
**Next steps**:
* Modify PR to keep tests related to new behavior for reference.
* Apply Myles' reverts (#7846, #7950)
* Apply `realpath` revert.
* Discuss other items (e.g. throw -> deprecation, proper realpath for subst'ed drives, cache impl) in GH issues.
---
### v4.5.0 proposal [#7688](https://github.com/nodejs/node/pull/7688)
@trott: Please test the RCs.
@mhdawson and @jasnell: Building at IBM and not encountered anything.
---
### build: drop support for VS 2013 in v7 [#7484](https://github.com/nodejs/node/issues/7484)
@bnoordhuis: Based on @joaocgreis’s comment we can move from 2013 without trouble.
@joshgav: @joaocgreis tested against many modules and with CITGM and encountered no problems.
@piscisaureus: Can we wait for semver-major?
@joshgav: Then we’ll be stuck with 2013 through out v6 LTS.
@piscisaureus: Should we make another issue for v6?
@jasnell: Let’s get this landed in master and test it out, then make a decision on putting in v6 before October.
@trott: Getting pretty close, don’t want to be switching just a month before.
**Next steps**:
* Merge to master and test.
* Determine in September if we can apply in v6.
---
### http: don't inherit from Object.prototype [#6102](https://github.com/nodejs/node/pull/6102)
@chrisdickinson has concerns, @mscdex contacted. No response yet.
@Fishrock123: Let’s remove `ctc-agenda` tag for next week.
@jasnell: Plenty of discussion, heard from Doug Wilson that it’s a positive change. Would rather not hold up waiting for a response. Would be best to land before v7.
@ofrobots: If we are going to change this we should have a plan for if/how we’ll get to maps.
@Fishrock123: There are too many people currently depending on this being a regular object.
@ofrobots: We shouldn’t break the ecosystem twice. We should target something with maps for v8 or longer timeframe.
@Fishrock123: Motivation is ?
Some feel we should wait for maps before making a breaking change. Jeremiah feels we should make an effective change now and not wait for an unknown future.
@Fishrock123: We’ll need to provide both old and new APIs side by side, and that could be hard to do with maps.
@ofrobots: We can delegate old API to a Proxy and add deprecation warnings on that handler.
@?: Is Proxy performant enough?
@ofrobots: For a deprecated path is it okay to take a performance hit?
@evan: Okay with current change proposal (i.e. to not inherit from Object) as long as it’s considered semver-major.
@jasnell will work on this.
**Next steps**: Decide whether to merge this or wait for maps-based impl.
---
### nodejs/node-eps proposal: WHATWG URL standard implementation [#28](https://github.com/nodejs/node-eps/pull/28)
@trott: briefing now, longer discussion next week.
@jasnell: Everyone keep reviewing it. Goal is to land as “experimental” in master, doesn’t have to go in v6.
@trevnorris: -1 on global `URL` variable.
@Fishrock123 also against new globals other than lang features.
@jasnell: It’s a global in browsers. It can be removed, it’s in its own commit.
**Next steps**: @nodejs/ctc review @jasnell's proposal. Discuss next week.
---
### doc: @piscisaureus has stepped-down from the CTC [#7969](https://github.com/nodejs/node/pull/7969)
@Fishrock123: submit PR to remove @piscisaureus and/or move to Collaborator.
---
## Q/A on public fora
No questions.
## Upcoming Meetings
* CTC: 2016-08-03
* TSC: 2016-07-28
* Build: 2016-08-07
* LTS: 2016-07-25
* Diagnostics: Sept
* Post-Mortem: August
* API: August

281
doc/ctc-meetings/2016-08-10.md

@ -1,281 +0,0 @@
# Node Foundation CTC Meeting 2016-08-10
## Links
* **Audio Recording**: TBP
* **GitHub Issue**: [#8030](https://github.com/nodejs/node/issues/8030)
* **Minutes Google Doc**: <https://docs.google.com/document/d/1L65L7qhX5MrGeFwrub4-Z8klrwxJym-Q8CIEZsedohE>
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/1ufR5dNuN3JLmFPvCvLYGRa98_-eqy5yY3zJuTnT60K8>_
## Present
* Anna Henningsen @addaleax (CTC)
* Bradley Meck @bmeck (observer/GoDaddy/TC39)
* Ben Noordhuis @bnoordhuis (CTC)
* Сковорода Никита Андреевич @ChALkeR (CTC)
* Colin Ihrig @cjihrig (CTC)
* Evan Lucas @evanlucas (CTC)
* Jeremiah Senkpiel @Fishrock123 (CTC)
* Tracy Hinds @hackygolucky (observer/Node.js Foundation)
* James M Snell @jasnell (CTC)
* Josh Gavant @joshgav (observer/Microsoft)
* Michael Dawson @mhdawson (CTC)
* Brian White @mscdex (CTC)
* Ali Ijaz Sheikh @ofrobots (CTC)
* Myles Borins @TheAlphaNerd (observer/IBM)
* Trevor Norris @trevnorris (CTC)
* Rich Trott @Trott (CTC)
## Standup
* Anna Henningsen @addaleax (CTC)
* Issues/PR review
* Bradley Meck @bmeck (observer/GoDaddy/TC39)
* Came up with overhauled plan for Module moving forward
* Сковорода Никита Андреевич @ChALkeR (CTC)
* A bit more work on the ecosystem detection tool
* Mostly comments, nothing significant
* Will file a docs linting PR soon — needs some final cleanup
* Colin Ihrig @cjihrig (CTC)
* Reviewing issues and PRs
* Working on the v6.4.0 release
* Evan Lucas @evanlucas (CTC)
* some more commit validation work
* backport pr for worker.exitedAfterDisconnect to v4.x
* Jeremiah Senkpiel @Fishrock123 (CTC)
* Nothing in particular
* Tracy Hinds @hackygolucky (observer/Node.js Foundation)
* James M Snell @jasnell (CTC)
* Going through PRs/Issues
* More exploration of possibility of HTTP/2 impl in core
* Other miscellaneous things
* Josh Gavant @joshgav (observer/Microsoft)
* meetings notes
* review some issues
* Michael Dawson @mhdawson (CTC)
* adding linxuOne release machine to the release CI, and getting linuxOne added to release job so that we get nightlies for that platform
* configuring new AIX machines from osuosl, adding to CI and validating with AIX build jobs that they look good. Working to get added to regular regression jobs.
* Working on build wg, FIPs and post-mortem presentations for Node interactive Europe
* Landing a few PRs
* Reading/commenting on issues
* Participation in LTS and Build WGs
* ABI stable API PoC
* Brian White @mscdex (CTC)
* Reviewing PRs, commenting on issues
* Ali Ijaz Sheikh @ofrobots (CTC)
* v8_inspector updates, V8 backports, writing up a doc on maintaining V8
* Myles Borins @TheAlphaNerd (observer/IBM)
* v4.5.0 testing (potential regression)
* ABI Smoke Testing Job
* Landing V8 5.1 on v6.x
* junit reporters for CI with Johann
* Trevor Norris @trevnorris (CTC)
* PR reviews
* Vacation most of the week
* Rich Trott @Trott (CTC)
* onboarded @fhinkel
* minor work on tests
* ESLint update, minor indentation rule update
* Steven Loomis (Observer)
* Asked me to pass on his regrets as he’s on vacation.
* He’s been working on more Intl related items.
## Agenda
Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting.
### nodejs/node
* v4.5.0 proposal [#7688](https://github.com/nodejs/node/pull/7688)
* buffer: hard-deprecate Buffer constructor [#7152](https://github.com/nodejs/node/pull/7152)
* Revert "fs: add a temporary fix for re-evaluation support" [#6413](https://github.com/nodejs/node/pull/6413)
* errors: add internal/errors module [#6573](https://github.com/nodejs/node/pull/6573)
* Introduce staging branch for stable release streams [#6306](https://github.com/nodejs/node/issues/6306)
### nodejs/node-eps
* proposal: WHATWG URL standard implementation [#28](https://github.com/nodejs/node-eps/pull/28)
### general
* discussion: CommonJS and ES6 modules interoperability (<https://gist.github.com/bmeck/52ee45e7c34d1eac44ce8c5fe436d753>)
## Previous Meeting
### nodejs/node
* CTC membership nomination: @addaleax [#7607](https://github.com/nodejs/node/issues/7607)
* Revert fs changes [#7846](https://github.com/nodejs/node/pull/7846)
* [meta] realpath issues in v6 [#7726](https://github.com/nodejs/node/issues/7726)
* v4.5.0 proposal [#7688](https://github.com/nodejs/node/pull/7688)
* build: drop support for VS 2013 in v7 [#7484](https://github.com/nodejs/node/issues/7484)
* New issue specifically for v6: [#7989](https://github.com/nodejs/node/issues/7989)
* http: don't inherit from Object.prototype [#6102](https://github.com/nodejs/node/pull/6102)
### nodejs/node-eps
* proposal: WHATWG URL standard implementation [#28](https://github.com/nodejs/node-eps/pull/28)
## Minutes
### v4.5.0 proposal [#7688](https://github.com/nodejs/node/pull/7688)
@thealphanerd: investigating problem with Bower, may delay release, if so will notify everyone.
**Next steps**:
* As above.
---
### buffer: hard-deprecate Buffer constructor [#7152](https://github.com/nodejs/node/pull/7152)
@trevnorris: In the future the Buffer function will need to be a proper class so that `iterate` can return a buffer and so that users can inherit from Buffer.
Enabling inheritance forces the use of `new`. Thus it will break anyone who uses `Buffer` without the `new` keyword.
@evanlucas: Wasn’t there a way around that?
Perhaps with use of @@species symbol, but still doesn’t remove the fact that we’ll need to remove the `new` keyword at some point.
@addaleax: We could work around using `Reflect` API and check if call was made with `new` or not. There were perf concerns, @RReverser worked on something (see <https://github.com/nodejs/node/pull/7152#discussion_r74932064>).
@evanlucas: Can we do that and just soft-deprecate not using `new`?
@jasnell: We should absolutely *not* deprecate `new Buffer(...)`.
@chalker: [Deprecating `new Buffer()` will force libraries to work around this in 0.10, 0.12, and LTS <4.4, doesnt sound like a good thing to do now.
**Next steps**:
* Continue discussion in GitHub.
* Finalize decision next week.
---
### Revert "fs: add a temporary fix for re-evaluation support" [#6413](https://github.com/nodejs/node/pull/6413)
Do we land the revert?
@chalker: This is going to break modules, notably those which depend on `graceful-fs`, including `gulp` and `unzip` (there’s another unzip module people use, unzip is not updated for a long time and its usage is rapidly decreasing), other inactive modules.
gulp will update `graceful-fs` Gulp v4. Gulp accounts for 42% of usage of `graceful-fs`. Gulp doesn’t want to update `graceful-fs` in v3 because it's a semver-major change, wants to wait for semver-major update till v4.
@jasnell: If we keep it as is I don’t think the modules are going to get fixed.
@thealphanerd: if gulp v3 isn’t updated then it will continue to cause problems for people through v7 lifetime. Can gulp do something to make this easier on the community?
@thealphanerd will follow up with gulp project leads about updating `graceful-fs` in Gulp v3.
@chalker: Old version of `graceful-fs` now includes its own message that it will be broken in Node v7. Would be best to live up to our commitment.
**Next steps**:
* Myles to follow up with Gulp about changes in v3, notify CTC as appropriate.
* Finalize decision next week.
---
### proposal: WHATWG URL standard implementation [#28](https://github.com/nodejs/node-eps/pull/28)
Should `url` be a global or not?
@jasnell: To start let’s just not make it a global.
@jasnell: No need to include this in v6; include in master and in v7.
First step is to decide to land this as an EP in Node-EPs. Then, consider implementation.
@evanlucas: Will the similarity of these cause confusion?
`require(‘url’).Url` and `require(‘url’).URL`.
@jasnell: best answer is I’m not sure yet.
@jasnell: We’ll move forward on the EP without the global.
**Next steps**:
* Remove global then land EP.
* Continue work/review on impl.
---
### errors: add internal/errors module [#6573](https://github.com/nodejs/node/pull/6573)
@jasnell: This begins the process of changing errors implementation so that changes to their text are not semver-major.
Do we want this to land in v7? If we do, it needs to be complete by the end of August.
@Fishrock123: think about whether we can keep the syntax similar between js and c++.
@jasnell: if additional work is needed for C errors we should not rush it.
**Next steps**:
* Review in GitHub.
* Finalize next week.
---
### Introduce staging branch for stable release streams [#6306](https://github.com/nodejs/node/issues/6306)
@thealphanerd: If we had a staging branch we’d avoid blocking releases due to problematic commits.
@Fishrock123: You can already stage to `v6.x` but usually people don’t do that.
@thealphanerd: Since it has the same function as `staging` it would be good to name them similarly.
@bnoordhuis: it’s confusing that there are different ways to get PRs backported in different branches.
@Fishrock123: Actual practices are not likely to change.
**Next steps**:
* Continue discussion in GH.
* Keep on agenda.
---
### discussion: CommonJS and ES6 modules interoperability (see <https://gist.github.com/bmeck/52ee45e7c34d1eac44ce8c5fe436d753>)
@bmeck:
* Cannot match babel’s semantics.
* Cannot support named imports from CJS modules.
We cannot match babel’s semantics so whatever happens in the future, at a minimum people who use babel to compile will have to change to use whatever Node is using for ES modules.
There’s no real way for us to support named imports from CJS modules, so these will be imported as the `default` property only, so people will not be able to use just `readFile` from `fs`.
Those 2 breakages mean we have to rethink this. First route was to match babel.
@bmeck proposes Node does a hard break. Remove most of Node’s magic names.
We’ll need a separate WHATWG `registry` object
@bmeck: New features are going to be targeting the module grammar exclusively. For example, `await` is not a keyword in the script grammar and if it’s treated that way it’s a language extension. TC39 considers `script` somewhat legacy.
**Next steps**:
* Schedule a session specifically on modules.
---
## Q/A on public fora
Q: Regarding WHATWG URL, how will updates be handled - major, minor, bug fix?
@jasnell: Still need to figure out process. Currently monitoring WHATWG to get a sense of their process. If their change is semver-major ours would presumably also be.
## Upcoming Meetings
* CTC: 2016-08-17
* TSC: 2016-08-11
* Build: Sept
* LTS: Sept
* Diagnostics: Sept
* Post-Mortem: Sept
* API: Sept

300
doc/ctc-meetings/2016-08-17.md

@ -1,300 +0,0 @@
# Node Foundation CTC Meeting 2016-08-17
## Links
* **Audio Recording**: TBP
* **GitHub Issue**: [#8125](https://github.com/nodejs/node/issues/8125)
* **Minutes Google Doc**: <https://docs.google.com/document/d/10fKK2lyZrxJ1Gt4zJvVSIsfmTGVD547vJJOp6eVKk-k>
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/1L65L7qhX5MrGeFwrub4-Z8klrwxJym-Q8CIEZsedohE>_
## Present
* Anna Henningsen @addaleax (CTC)
* Bradley Meck @bmeck (observer/GoDaddy/TC39)
* Ben Noordhuis @bnoordhuis (CTC)
* Сковорода Никита Андреевич @ChALkeR (CTC)
* Colin Ihrig @cjihrig (CTC)
* Evan Lucas @evanlucas (CTC)
* Jeremiah Senkpiel @Fishrock123 (CTC)
* Tracy Hinds @hackygolucky (observer/Node.js Foundation)
* James M Snell @jasnell (CTC)
* Josh Gavant @joshgav (observer/Microsoft)
* Julien Gilli @misterdjules (CTC)
* Ali Ijaz Sheikh @ofrobots (CTC)
* Rod Vagg @rvagg (CTC)
* Myles Borins @TheAlphaNerd (observer)
* Trevor Norris @trevnorris (CTC)
* Rich Trott @Trott (CTC)
## Standup
* Anna Henningsen @addaleax (CTC)
* Issues & PR review
* Bradley Meck @bmeck (observer/GoDaddy/TC39)
* Modules - talks w/ transpilers about paths forward , looks like clean break / may not be able to support forward transpilation
* Сковорода Никита Андреевич @ChALkeR (CTC)
* Comments on issues and PRs
* Colin Ihrig @cjihrig (CTC)
* v6.4.0 release
* Reviewed issues and PRs
* Evan Lucas @evanlucas (CTC)
* some small doc updates
* pr to revert \r\n change to util/repl
* Jeremiah Senkpiel @Fishrock123 (CTC)
* only a few PR/Issue comments
* Tracy Hinds @hackygolucky (observer/Node.js Foundation)
* working on inclusivity strategies, stay tuned for issues in the next few days
* certification scoping: reach out to me if you’d like to be part of that
* James M Snell @jasnell (CTC)
* PR review
* More investigation into HTTP/2
* Work on proposed icu module
* Some inclusivity related discussions
* Josh Gavant @joshgav (observer/Microsoft)
* onboarded!
* internal work
* Julien Gilli @misterdjules (CTC)
* soliciting feedback on testing release candidates from customers
* Brian White @mscdex (CTC)
* Submitted a couple of small PRs
* Reviewed PRs, commented on issues
* Ali Ijaz Sheikh @ofrobots (CTC)
* Auditing upstream bug fixes on V8
* Rod Vagg @rvagg (CTC)
* Taking time off
* Myles Borins @TheAlphaNerd (observer)
* Released v4.5.0
* Landed **fix** into graceful-fs
* continued research into how to minimize ecosystem breakage with fs changes
* continued work on V8 ABI testing for citgm
* New native modules included in citgm
* CI job in jenkins
* Trevor Norris @trevnorris (CTC)
* Nothing of note
* Rich Trott @Trott (CTC)
* Onboarding @joshgav
* ESLint updates and enabling of rules
* small tests to plug holes in test coverage (per @addaleax’s coverage web page https://node-core-coverage.addaleax.net/)
## Agenda
Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting.
### nodejs/node
* CTC membership nomination: @TheAlphaNerd [#8058](https://github.com/nodejs/node/issues/8058)
* buffer: hard-deprecate Buffer constructor [#7152](https://github.com/nodejs/node/pull/7152)
* Revert "fs: add a temporary fix for re-evaluation support" [#6413](https://github.com/nodejs/node/pull/6413)
* Introduce staging branch for stable release streams [#6306](https://github.com/nodejs/node/issues/6306)
* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979)
## Previous Meeting
Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting.
### nodejs/node
* v4.5.0 proposal [#7688](https://github.com/nodejs/node/pull/7688)
* @thealphanerd will investigate problem with Bower, may delay release, if so will notify everyone.
* buffer: hard-deprecate Buffer constructor [#7152](https://github.com/nodejs/node/pull/7152)
* Continue discussion in GitHub.
* Finalize decision next week.
* Revert "fs: add a temporary fix for re-evaluation support" [#6413](https://github.com/nodejs/node/pull/6413)
* Myles to follow up with Gulp, notify CTC as appropriate.
* Finalize decision next week.
* errors: add internal/errors module [#6573](https://github.com/nodejs/node/pull/6573)
* Review in GitHub.
* Finalize next week.
* **Decided not to discuss today, continue work in GH.**
* Introduce staging branch for stable release streams [#6306](https://github.com/nodejs/node/issues/6306)
* Continue discussion in GH.
* Keep on agenda.
### nodejs/node-eps
* proposal: WHATWG URL standard implementation [#28](https://github.com/nodejs/node-eps/pull/28)
* Remove global than land EP.
* Continue work/review on impl.
### general
* discussion: CommonJS and ES6 modules interoperability (<https://gist.github.com/bmeck/52ee45e7c34d1eac44ce8c5fe436d753>)
* Schedule a session specifically on modules.
## Minutes
### CTC membership nomination: @TheAlphaNerd [#8058](https://github.com/nodejs/node/issues/8058)
Generally we require attendance as an observer at least 4 times to ensure fit on both sides. Myles has already attended several meetings and all are comfortable.
We will vote on this next week.
**Next steps**:
* Vote next week.
---
### buffer: hard-deprecate Buffer constructor [#7152](https://github.com/nodejs/node/pull/7152)
In order to enable inheritance from Buffer, need to declare it as a class, which will then require `new` keyword to create a new Buffer.
`new Buffer(...)` works in all versions.
Options
1. Keep as is - `Buffer(...)` would still work without `new`, and Buffer wouldn’t be subclassable.
2. Deprecate creating a buffer without `new`. `Buffer(...)` would no longer work.
3. Fully deprecate any use of Buffer constructor even without `new`. Neither `Buffer(...)` nor `new Buffer(...)` would work.
@trevnorris: Another option is to retain UInt8Array constructor signatures as Buffer constructor signatures.
@Fishrock123: We should deprecate use without `new`, but deprecating entire constructor isn’t reasonable due to ecosystem usage.
@jasnell: It would be a hard deprecation warning, i.e. by default print a warning message.
@trott: That would imply full removal in v9.x at the earliest.
@trevnorris: ecosystem has to use workarounds to subclass Buffer. So this refactor is actually blocking use cases.
@Fishrock123: We could differentiate between `require(‘buffer’).Buffer` and the global `Buffer`; imported Buffer would have deprecation, but Buffer as a global would not have that deprecation.
@addaleax: No. The types should still match (behave the same).
@jasnell: Separate into 2 PRs: one for deprecation of `Buffer()` without `new`, and another for complete deprecation of constructor, even with `new`.
**Next steps**:
* Separate into 2 PRs as above.
* Discuss again next week.
---
### Revert "fs: add a temporary fix for re-evaluation support" [#6413](https://github.com/nodejs/node/pull/6413)
@thealphanerd: Making many patches in `graceful-fs` and concerned that will not scale.
Previously graceful-fs put something through `vm` module. Then we used something in `internal/util` and it blew everything up. This happened near v6 release so we added this temporary fix.
Now this temporary fix is blocking progress on other issues.
We’ve had to patch `graceful-fs` several times, no guarantee that we won’t have to again. Each time it’s putting internal/util methods directly into graceful-fs.
Gulp transitively relies on graceful-fs v3.
Myles spoke to Blaine (head of gulp). Very reluctant to make a breaking change within v3 major release. Nothing seems to be broken, Myles ran tests, but not every possible workflow.
[#8149](https://github.com/nodejs/node/issues/8149) opened by @isaacs to discuss benefits of `internal`, worth discussing this in that context.
We want to move things to `internal` but we also don’t want to break gulp and the ecosystem (e.g. ember CLI).
@Fishrock123: Why can’t we use the updated shim to make graceful-fs v2 and v3 work?
Myles: More changes coming that will further break graceful-fs, such as [#6749](https://github.com/nodejs/node/pull/6749), the Errors PR James is working on, a PR to move StringToFlags to internal/fs.
Reasons to stop treating graceful-fs specially:
* We’ll need to patch graceful-fs v2 whenever we patch `internal/fs`.
* New things could be added to `internal` in `nodejs/node` which we don’t expect to be relevant to the ecosystem but in fact will need to be added graceful-fs.
@rvagg: Perhaps we should move slower, graceful-fs is an important module.
@jasnell: Consider errors PR, helps us reduce inconsistencies and problems. We’d need alternate code in graceful-fs to do that.
We are doing that currently with streams. I have to treat it special cause of the `readable-stream` module.
It makes things significantly harder.
@thealphanerd: Should we shim `process.binding('internal/*')` to intercept this call and return patched module when needed?
@thealphanerd: Let’s add graceful-fs v3 to CITGM and ensure it keeps working.
@jasnell: perhaps we should have our own `graceful-fs` module in core.
@Fishrock123: Let’s backport all patches in graceful-fs v4 to v3 and v2.
@Chalker: This is what gulp objects to, they can’t backport to make a semver-major change.
@Fishrock123: If in fact it’s not breaking then they should backport them.
@jasnell: We need to decide if we want to land before v7. This particular PR, if landed, would not break `graceful-fs` v3. (Myles: but it would break v2).
@rvagg: I’d vote for slowing down on this. This group is not a primary group of Node users, they’re using for frontend toolchain. They aren’t used to dealing with Node and won’t know how to handle problems. Better for us to accept a little pain than to inflict on lots of users.
@bnoordhuis: if not now when?
@myles: graceful-fs v2 patch wouldn’t take a long time.
A lot of people in ecosystem who don’t feel like we’re listening. There’s not much technical advantage to landing this. (We could update the patch to use an updated form of deprecation.)
On the other hand, to land all the other fs fixes we need to land this.
So if we’re going to land the rest, we should land this. Otherwise, hold.
@jasnell: no consensus to land this before v7. Next possible time is v8.x (which becomes LTS).
@thealphanerd: still possible to land in v7.
@bnoordhuis: What might change in v8.x timeframe?
@thealphanerd: more gulp v4 adoption, more ecosystem testing to see how to avoid breaking people.
@trevnorris: will the ecosystem upgrade from v3 to v4?
@thealphanerd: at least they’ll have the option to upgrade and be unbroken.
**Next steps**:
* Myles working with @isaacs to integrate a fix in graceful-fs@3 to address all these concerns, see <https://github.com/nodejs/node/pull/8245#issuecomment-242192458>.
---
### Introduce staging branch for stable release streams [#6306](https://github.com/nodejs/node/issues/6306)
Deferred till next week.
---
### Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979)
@rvagg to follow up with legal committee.
---
### Modules Update (from Bradley)
@jasnell will set up a Doodle for a meeting on modules.
---
## Q/A on public channels
Q: Where should the question of accepting creationix/nvm go?
[TSC#96](https://github.com/nodejs/TSC/issues/96)
@jasnell: TSC meeting, add to next week’s agenda.
## Upcoming Meetings
* CTC: 2016-08-24
* TSC: 2016-08-25
* Benchmarking: [Benchmarking#56](https://github.com/nodejs/benchmarking/issues/56)
* Build:
* LTS:
* Diagnostics:
* Post-Mortem:
* API:

328
doc/ctc-meetings/2016-08-24.md

@ -1,328 +0,0 @@
# Node Foundation CTC Meeting 2016-08-24
## Links
* **Audio Recording**: TBP
* **GitHub Issue**: [#8242](https://github.com/nodejs/node/issues/8242)
* **Minutes Google Doc**: <https://docs.google.com/document/d/1mkOUQ-M3s6zV2ige00hj6IIlT5oGQcw1USeliRqRDSk>
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/10fKK2lyZrxJ1Gt4zJvVSIsfmTGVD547vJJOp6eVKk-k>_
## Present
* Anna Henningsen @addaleax (CTC)
* Bradley Meck @bmeck (observer/GoDaddy/TC39)
* Сковорода Никита Андреевич @ChALkeR (CTC)
* Jeremiah Senkpiel @Fishrock123 (CTC)
* Fedor Indutny @indutny (CTC)
* James M Snell @jasnell (CTC)
* Josh Gavant @joshgav (observer/Microsoft)
* Michael Dawson @mhdawson (CTC)
* Julien Gilli @misterdjules (CTC)
* Brian White @mscdex (CTC)
* Jenn Turner @renrutnnej (observer/Node.js Foundation)
* Rod Vagg @rvagg (CTC)
* Steven R Loomis @srl295 (observer/IBM/ICU)
* Myles Borins @TheAlphaNerd (observer)
* Trevor Norris @trevnorris (CTC)
* Rich Trott @Trott (CTC)
## Standup
* Anna Henningsen @addaleax (CTC)
* Issues & PR review
* Couple of own PRs
* Bradley Meck @bmeck (observer/GoDaddy/TC39)
* Started rewrite/overhaul of Module EP
* Сковорода Никита Андреевич @ChALkeR (CTC)
* Comments on issues and PRs, nothing significant
* Started documenting my npm tooling
* Jeremiah Senkpiel @Fishrock123 (CTC)
* Minor PR & Issue things
* Review of the Promises Warnings thing
* Fedor Indutny @indutny (CTC)
* Reviewing PRs, nothing fancy
* James M Snell @jasnell (CTC)
* PR review
* Josh Gavant @joshgav (observer/Microsoft)
* Issue review, keep CTC notes in order
* Michael Dawson @mhdawson (CTC)
* Away on vacation last week
* Fixed up problems with acme air benchmarks
* Investigated AIX machine issues (firewall problem)
* misc PR review/land
* catching up on issues
* starting to add new PPC machines (hopefully final set)
* Julien Gilli @misterdjules (CTC)
* making libuv test suite pass on SmartOS
* Brian White @mscdex (CTC)
* My continuing mission: to explore strange new deopts, to seek out new JS and new optimizations.
* Reviewing PRs, commenting on issues
* Jenn Turner @renrutnnej (observer/Node.js Foundation)
* Observing in prep for a newsletter on Node community with
Node.js Foundation
* Rod Vagg @rvagg (CTC)
* Taking it easy, some discussion, some meetings
* Steven R Loomis @srl295 (observer/IBM/ICU)
* Achievement unlocked: getting to CTC call
* Myles Borins @TheAlphaNerd (observer)
* (on vacation)
* Trevor Norris @trevnorris (CTC)
* async wrap; considering changing the name of public API require.
* Rich Trott @Trott (CTC)
* Multiple issues causing CI yellow and red this week. Will file an issue for next meeting for things we may wish to do differently.
* Helped three first-time contributors get their first commits in. (Well, two of them so far.) Some documentation changes have/will come from this.
* Lots of small PRs to refactor tests.
## Agenda
Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting.
### nodejs/node
* CTC membership nomination: @TheAlphaNerd [#8058](https://github.com/nodejs/node/issues/8058)
* buffer: hard-deprecate Buffer constructor [#7152](https://github.com/nodejs/node/pull/7152)
* fs: don't alter user provided `options` object [#7831](https://github.com/nodejs/node/pull/7831)
* fs: undeprecate existsSync; use access instead of stat for performance [#7455](https://github.com/nodejs/node/pull/7455)
* doc: add Google Analytics tracking. [#6601](https://github.com/nodejs/node/pull/6601)
* Introduce staging branch for stable release streams [#6306](https://github.com/nodejs/node/issues/6306)
* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979)
### nodejs/api
* Landing node-eps for ABI stable module and location for PoC code [#28](https://github.com/nodejs/api/issues/28)
## Previous Meeting
Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting.
* CTC membership nomination: @TheAlphaNerd [#8058](https://github.com/nodejs/node/issues/8058)
* vote next week
* buffer: hard-deprecate Buffer constructor [#7152](https://github.com/nodejs/node/issues/7152)
* separate into 2 PRs (one for deprecation without `new`, one for deprecation even with `new`)
* revisit next week
* Revert "fs: add a temporary fix for re-evaluation support" [#6413](https://github.com/nodejs/node/6413)
* Discussion continuing in GitHub.
* Introduce staging branch for stable release streams [#6306](https://github.com/nodejs/node/6306)
* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/3979)
## Minutes
### CTC membership nomination: @TheAlphaNerd [#8058](https://github.com/nodejs/node/issues/8058)
@trott: Any objections?
Vote: Unanimous yes. No “nos” or official “abstains.”
**Next steps**:
* @rvagg to onboard @thealphanerd.
---
### buffer: hard-deprecate Buffer constructor [#7152](https://github.com/nodejs/node/pull/7152)
@addaleax: See <https://github.com/nodejs/node/pull/7152#issuecomment-241355246>
@jasnell and @rvagg both posted following @addaleax, she agrees.
@addaleax: Not in favor of dropping constructors which don’t match UInt8Array constructors.
@jasnell: What is the use case that requires `Buffer` be subsclassable?
@trevnorris: It cleans up the code if we can extend directly from UInt8Array. Also, community members have requested the ability to extend Buffer.
@addaleax: We could work around that, we could export something from `require(‘Buffer’)` which is subclassable.
@trevnorris: But your constructor name won’t be right.
@addaleax: I posted a proof of concept, I think everything is going to be right, needs perf evaluation.
@trott: One issue is whether and when to deprecate `Buffer` without `new` keyword. Any dissent on that?
@jasnell: Haven’t seen any dissent.
@trott: Can we finalize on that?
@trevnorris: to extend from UInt8Array all we need to do is deprecate `Buffer` without `new`.
@jasnell: We all agree about removing `new` - hard deprecation.
@joshgav: Can you clarify what is meant by “soft” and “hard” deprecation?
@jasnell: "soft" means documentation only. "hard" means throw an error by default, or with command-line flag print a warning instead.
@trott: Other question re deprecating constructors with `new` is not as clear. Do we need to figure this out now?
@jasnell: Recommend waiting, it’s more nuanced.
@addaleax: I agree. Maybe in v8.x.
@trevnorris: We can’t flatly deprecate all use cases of `new Buffer(...)`.
**Next steps**:
* Land hard deprecation of `Buffer` without `new` now.
* Other conversation continue in GH, remove ctc-agenda label.
---
### fs: don't alter user provided `options` object [#7831](https://github.com/nodejs/node/pull/7831)
@FishRock123: while using `util._extend` would be a semver-major break, does it actually break anything?
@indutny: It’s just a side effect, not major.
@FishRock123: should still be a semver-major change, but not something to worry about.
@rvagg: We’ve landed these types of changes in the past without waiting for semver-major.
@indutny takes back his words, it’s semver-major.
@trott: Seems pretty low risk for a semver-major.
@indutny: yes
@trott: post comments in GH if you have concerns, otherwise semver-major change is okay. What else?
@rvagg: This is just due diligence, there’s already use of utils._extend(...) in there.
@chalker: why did we have a test which passed an `Object.create()`-ed options object to it? [No objections].
**Next steps**:
* CTC approved semver-major change. Remove ctc-agenda, continue with usual process.
---
### fs: undeprecate existsSync; use access instead of stat for performance [#7455](https://github.com/nodejs/node/pull/7455)
Action requested: Is it okay to undeprecate existsSync()?
@Fishrock123: There is a use case for a file which exists but has no content - `.git/rebase-apply/rebasing`. Existence itself is a flag.
Also includes change to use `fs.access`, I don’t think that’s reasonable.
@rvagg: only undeprecates `existsSync`, not `exists`.
@chalker: I’d be okay with that.
@trott: Postpone till next week to allow for review?
**Next steps**:
* First item on next week’s agenda.
---
### doc: add Google Analytics tracking. [#6601](https://github.com/nodejs/node/pull/6601)
@FishRock123: Was this fixed to not include GA for local usage?
@chalker: Ben isn’t here and has opinions.
@rvagg: Marketing and web site team want analytics to understand how docs are used. The objections are about user privacy, and there was a suggestion that we manage our own analytics. But there was a non-trivial cost.
@rvagg: Only for the online docs, not the tarball etc. I’m okay with this.
@trott: It’s a legitimate need for access, I have no concerns.
@trevnorris: Is this to put analytics tracking inside the docs repo?
@Fishrock123: PR replaces a line and puts in the GA link/script.
@rvagg: Has to be included via a special flag to make. Will only be set when building for web site.
@misterdjules: A DNT flag has been added too, that may address some concerns.
@Chalker: DNT flag makes this acceptable. What will we use the stats for? To improve docs?
See <https://github.com/nodejs/node/pull/6601#issuecomment-224002869>
@rvagg: My only concern is moving forward without @bnoordhuis, who was the main holdout based on strong privacy objections.
@indutny: I don’t like the idea of being tracked. Considering that other parts of web site do tracking it may be more acceptable. An important question is what people will have access to these statistics? Has it been made clear?
@rvagg: Good question. Probably at least @mikeal.
@trott: Raise these questions in GitHub. We’ll put this back on the agenda for a quick resolution next week.
**Next steps**:
* Raise above questions and discuss in GH.
* Review for quick resolution next week.
---
### Introduce staging branch for stable release streams [#6306](https://github.com/nodejs/node/issues/6306)
Defer to next week when @thealphanerd is back.
**Next steps**:
* Defer to next week.
---
### Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979)
@rvagg has action to follow up, particularly on LICENSE file.
**Next step**:
* @rvagg to remove `ctc-agenda` label
---
### Landing node-eps for ABI stable module and location for PoC code [#28](https://github.com/nodejs/api/issues/28)
@mhdawson: EP has a view of what we’re trying to do, it’s definitely not the final version. But having it only as a PR makes it harder for others to collaborate on it. Can we merge it in draft status? Or perhaps move to another forum where we can collaborate more easily?
@misterdjules: Node-EPs repo says it’s okay to commit a draft.
@mhdawson: Then I’ll do that.
@mhdawson: Progress on POC code in a personal GitHub org, would like to put somewhere more visible, such as a repo in github.com/nodejs, or a branch in github.com/nodejs/node.
@Fishrock123: Maybe we should consolidate all experimental stuff (e.g. this, HTTP/2) in a nodejs/experimental repo?
@misterdjules: Are there concerns with new branches on main repo?
@Fishrock123: If there will be a lot of PRs and issues related to this branch it may block up the issue tracker.
@mhdawson: Issues will continue in nodejs/api repo.
@indutny: I don’t want to establish a precedent of having experimental branches in main repo. We had problems in past with cleaning these up. Having in a separate repo should simplify things.
@mhdawson: Would nodejs/node-experimental make sense, with different branches for different features?
@misterdjules: better not to centralize a lot of unrelated branches in a single repo.
@jasnell: do the same as I did for HTTP/2 repo, fork from nodejs/node into a new repo within github.com/nodejs.
@mhdawson: I’ll create another repo within github.com/nodejs.
**Next steps**:
* @mhdawson to commit draft to Node-EPs repo.
* @mhdawson to create another repo for ABI-stable work.
### Other:
Modules meeting: <http://doodle.com/poll/s4gcm28vmrdd3bqd>
## Q/A on public channels
None
## Upcoming Meetings
* CTC: 2016-08-31
* TSC: 2016-08-25
* Benchmarking: [Benchmarking#56](https://github.com/nodejs/benchmarking/issues/56)
* Build:
* LTS:
* Diagnostics:
* Post-Mortem:
* API:

315
doc/ctc-meetings/2016-08-31.md

@ -1,315 +0,0 @@
# Node Foundation CTC Meeting 2016-08-31
## Links
* **Audio Recording**: TBP
* **GitHub Issue**: [#8330](https://github.com/nodejs/node/issues/8330)
* **Minutes Google Doc**: <https://docs.google.com/document/d/1qYUOfiiytaZ0-YZVZ1NZX9O-4SE28QNooapOdcjlPqA>
* _Previous Minutes Google Doc_: <https://docs.google.com/document/d/1mkOUQ-M3s6zV2ige00hj6IIlT5oGQcw1USeliRqRDSk>
## Present
* Anna Henningsen @addaleax (CTC)
* Bradley Meck @bmeck (observer/GoDaddy/TC39)
* Сковорода Никита Андреевич @ChALkeR (CTC)
* Evan Lucas @evanlucas (CTC)
* Jeremiah Senkpiel @Fishrock123 (CTC)
* Fedor Indutny @indutny (CTC)
* James M Snell @jasnell (CTC)
* Josh Gavant @joshgav (observer/Microsoft)
* Michael Dawson @mhdawson (CTC)
* Mikeal Rogers @mikeal (observer/Node.js Foundation)
* Brian White @mscdex (CTC)
* Ali Ijaz Sheikh @ofrobots (CTC)
* Jenn Turner @renrutnnej (observer/Node.js Foundation)
* Rod Vagg @rvagg (CTC)
* Trevor Norris @trevnorris (CTC)
* Rich Trott @Trott (CTC)
## Standup
* Anna Henningsen @addaleax (CTC)
* Couple of own PRs
* Segfault issue in V8
* Issues & PR review
* Bradley Meck @bmeck (observer/GoDaddy/TC39)
* Going around sorting out the modules rewrite / explaining to people
* Сковорода Никита Андреевич @ChALkeR (CTC)
* Some work on the npm codesearch tool
* Usual comments on issues and PRs
* Evan Lucas @evanlucas (CTC)
* v6.5.0 release
* Jeremiah Senkpiel @Fishrock123 (CTC)
* Module discussions
* Reviewing promises warning & other PRs.
* Discovered more odd stdio related quirks.
* Fedor Indutny @indutny (CTC)
* Issues and PRs, nothing new
* Josh Gavant @joshgav (observer/Microsoft)
* Some work on debugging docs.
* Plan next Diag WG meeting.
* Michael Dawson @mhdawson (CTC)
* Addons on test issues on AIX
* Adding PPC machines from new cluster at OSUOSL
* Adding AIX machines from OSUOSL
* Adding linxuOne machine to release CI
* Initial discussion on codecoverage.nodejs.org
* Preparing for Node Interactive presentations (build WG update
Post-mortem WG update)
* General PR review/land/keeping up with issues
* Mikeal Rogers @mikeal (observer/Node.js Foundation)
* board meeting stuff from Monday
* getting things together for TC39 meeting
* Brian White @mscdex (CTC)
* Landed a couple of old PRs
* Reviewed PRs, commented on issues
* Ali Ijaz Sheikh @ofrobots (CTC)
* V8 5.1 and 5.4 related issues.
* Jenn Turner @renrutnnej (observer/Node.js Foundation)
* Observing for the Node.js Foundation newsletter
* Rod Vagg @rvagg (CTC)
* Node Foundation Board business (incl Board meeting), lots of Build WG work incl major ARM cluster cleanup, OSX resource chasing, clang 3.4.1 CI node, blog post
* Trevor Norris @trevnorris (CTC)
* Finishing async_hooks implementation
* Few PR reviews
* Posted issue about --prof not working on win x64 (when processing isolate*.log w/ --prof-process)
* Rich Trott @Trott (CTC)
* Onboarded @lpinca and @danbev
* Helped a few first-time and second-time committers, looking to do that more
* Trying to get CI green again, even ventured into C++/crypto land for a tiny change. #OutOfMyComfortZone Please review: https://github.com/nodejs/node/pull/8352
* James M Snell @jasnell (CTC)
* prs, issues, doc updates
* Preparing for v7
## Agenda
Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting.
### nodejs/node
* Process for determining supported platforms [#8265](https://github.com/nodejs/node/issues/8265)
* child_process, win: fix shell spawn with AutoRun [#8063](https://github.com/nodejs/node/pull/8063)
* fs: undeprecate existsSync; use access instead of stat for performance [#7455](https://github.com/nodejs/node/pull/7455)
* doc: add Google Analytics tracking. [#6601](https://github.com/nodejs/node/pull/6601)
* Introduce staging branch for stable release streams [#6306](https://github.com/nodejs/node/issues/6306)
* Move ecosystem detection tool to nodejs org [#7935](https://github.com/nodejs/node/issues/7935)
### nodejs/node-eps
* AsyncWrap public API proposal [#18](https://github.com/nodejs/node-eps/pull/18)
## Previous Meeting Review
* CTC membership nomination: @TheAlphaNerd [#8058](https://github.com/nodejs/node/issues/8058)
* @rvagg to onboard @thealphanerd.
* buffer: hard-deprecate Buffer constructor [#7152](https://github.com/nodejs/node/pull/7152)
* Land hard deprecation of `Buffer` without `new` now.
* Other conversation continue in GH, remove ctc-agenda label.
* fs: don't alter user provided `options` object [#7831](https://github.com/nodejs/node/pull/7831)
* CTC approved semver-major change. Remove ctc-agenda, continue with usual process.
* fs: undeprecate existsSync; use access instead of stat for performance [#7455](https://github.com/nodejs/node/pull/7455)
* First item on next week’s agenda.
* doc: add Google Analytics tracking. [#6601](https://github.com/nodejs/node/pull/6601)
* Raise above questions and discuss in GH.
* Review for quick resolution next week.
* Introduce staging branch for stable release streams [#6306](https://github.com/nodejs/node/issues/6306)
* Defer to next week.
* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979)
* @rvagg to remove `ctc-agenda` label
* Landing node-eps for ABI stable module and location for PoC code [#28](https://github.com/nodejs/api/issues/28)
* @mhdawson to commit draft to Node-EPs repo.
* @mhdawson to create another repo for ABI-stable work.
## Minutes
* fs: undeprecate existsSync; use access instead of stat for performance [#7455](https://github.com/nodejs/node/pull/7455)
@Fishrock123: No further discussion from us this past week.
Person who submitted PR analyzed `access` with F_OK flag but that didn’t reveal anything.
If we are to undeprecate something it needs CTC signoff.
@Trott: Is anyone strongly in favor?
@trevnorris: No super compelling reason for leaving it out, especially since this is something which has had a lot of community push to keep in.
@rvagg: This one needs a CTC or Collaborator champion to move it through, otherwise it will continue to be stalled.
@joshgav: Should we have someone come and present the case to the CTC?
@jasnell: That could be helpful.
@Fishrock123: All the cases are laid out in the thread.
@rvagg: Without a champion it won’t move forward. We need to ping collaborators and seek someone particularly interested.
@trevnorris: Code and tests are there. Do we need someone to come and make the argument?
@rvagg: Someone needs to come and do the convincing.
@trevnorris: There are people religiously opposed to this, no argument could win them over. I don’t have time to make all those arguments.
@mikeal: We can move to a vote then.
@trott: Let’s ping nodejs/collaborators to see if anyone feels very strongly in favor of `existsSync` and see where that lands, then look at this again in a week. If no one stands up for the case than whether just or not it’s dead in the water.
@rvagg: We can also have a vote here and just bring it down to proper voting.
@addaleax: @williamkapke suggested discussing this at the Collaboration Summit.
**Next steps**:
* @trott to ping nodejs/collaborators in that thread.
* If no response raise for vote next week or close.
### doc: add Google Analytics tracking. [#6601](https://github.com/nodejs/node/pull/6601)
@mikeal: People with access would be web site admin team and internal foundation employees.
@trott: We wanted to wait for @bnoordhuis to give input. But he’s not here again this week. Should we table?
@mikeal: No argument about value of this data, argument about which tool to use. But no alternative has been proposed.
@rvagg: We gave warning that we’d come back to it this week. We’re back so now it’s time to vote.
@indutny: My questions are answered, I don’t have any objections.
@trott: Anyone opposed to moving to a vote?
**Vote**:
* Yes: 9 (Rich Trott, Ali Sheikh, Evan Lucas, Anna Henningsen, Fedor Indutny, Rod Vagg, James Snell, Michael Dawson, Trevor Norris)
* No: 0
* Abstain: 3 (Brian White, Сковорода Никита, Jeremiah Senkpiel)
**Next steps**:
* Merge!
### Introduce staging branch for stable release streams [#6306](https://github.com/nodejs/node/issues/6306)
@trott: No rush, propose tabling another week to wait for @thealphanerd.
@evanlucas: Myles made his position pretty clear. At first I didn’t care either way, but after the last release it was difficult to not have a staging branch to build out on. I had built binaries and then something was added and I had to go back.
@jasnell: Most people who have done releases recently have come out in favor of this or at least not said absolutely not. We can try it and if it’s too much process we can go back to the way we’re doing it now.
@rvagg: I like Myles argument about consistency and helping people onboard. Agree with James that this is up to those doing releases. If they want this, so be it.
@Fishrock123: Consistency argument is reasonably compelling, but I thought that wasn’t the case.
**Vote**:
Aye: 11 (Jeremiah Senkpiel, Evan Lucas, Ali Sheikh, Anna Henningsen, Rich Trott, Rod Vagg, Trevor Norris, Brian White, Nikita, Fedor Indutny, Michael Dawson, James Snell)
Nay: 0
Abstain: 0
**Next steps**:
* Do this as proposed.
### Process for determining supported platforms [#8265](https://github.com/nodejs/node/issues/8265)
@rvagg: Build working group should build a list and we can start from there. Next Build WG meeting is in 3 weeks.
@rvagg: Not just about platforms, but many permutations of plats and arch’s.
**Next steps**:
* Build WG will prepare initial list of supported platforms in their next meeting.
* Then CTC will review and decide next steps.
### child_process, win: fix shell spawn with AutoRun [#8063](https://github.com/nodejs/node/pull/8063)
@joshgav: Someone filed a bug to not respect registered autorun programs in Windows cmd spawned from Node.
@rvagg: Others asked what other runtimes do, e.g. Python.
Seems to me if you have something in the autorun then we should respect that.
@joshgav: Probably Microsoft would argue against bypassing something configured to autorun.
@rvagg: We don’t have sufficient expertise here to decide. Was brought to CTC because it’s semver-major.
**Next steps**:
* Remove from CTC agenda.
* @joshgav to check for opinions within Microsoft.
* Ask @joaocgreis in GitHub for more explanation.
### Move ecosystem detection tool to nodejs org [#7935](https://github.com/nodejs/node/issues/7935)
@Chalker: Now it’s completely in JavaScript and it has documentation to allow people to use it, so I think it’s ready for moving in.
@trott: In the issue I see only supportive voices. Any questions or concerns?
@Fishrock123: Chris Dickinson (@chrisdickinson) did some work on making an indexer that could track code paths (?). Just an aside, it’d be nice to get his opinion.
@Chalker: This doesn’t use any database, it uses plain text and json files compressed with lz4.
@trott: Move to a vote?
@rvagg: Who would take responsibility for this? Directly under CTC? It’s own maintenance group? For example if there are controversial issues to resolve are they resolved by the CTC.
@Chalker: Not sure.
@rvagg: CTC probably doesn’t want to own this, so probably needs its own team/WG, and that should be in the README at least.
@mhdawson: Probably needs LICENSE, CONTRIBUTORS, etc. We’ve asked others to add those in, then open an issue in nodejs/tsc, then we move it over.
@rvagg: That seems absolutely right. Prepare it and put it on TSC repo. Ping @williamkapke for help if you need.
@mhdawson: Also node-report is an example of this exercise done recently, you can learn from that.
@trott: Any objections to this?
**Next steps**:
* Prep repo for migration.
* Open issue in nodejs/tsc.
### AsyncWrap public API proposal [#18](https://github.com/nodejs/node-eps/pull/18)
@trevnorris: Updated the EP some, updating again now. There was an API which was useless. Happy with progress, 80% of the way there. Will keep working on it, put up for review tomorrow morning. Other than that one change of removal of API it’s pretty much on point.
@rvagg: There was a question about renaming the API.
@trevnorris: The name ‘AsyncWrap’ is an implementation “leak”. So I’ve renamed it “async_hooks”. Want to verify that CTC is okay with name change.
@Fishrock123: A lot of new things have been added since CTC last reviewed.
@rvagg: Let’s bring this up again next week with a clear request for a vote.
Where is the code for review?
@trevnorris: cannot be done in pieces, it’s an all-or-none thing.
@joshgav: Do we want this to land before v7?
@Fishrock123: It’s semver-minor, so not a big deal.
@trevnorris: Plan was to get this in before v6 goes LTS. When is that?
@jasnell: mid to late October.
**Next steps**:
* Trevor to update all code and ask for vote on specific item(s).
* CTC to review again once complete.
## Q/A on public channels
None.
## Upcoming Meetings
* CTC: 2016-09-07
* TSC: 2016-09-08
* Benchmarking: [Benchmarking#56](https://github.com/nodejs/benchmarking/issues/56)
* Build:
* LTS:
* Diagnostics:
* Post-Mortem:
* API:

245
doc/ctc-meetings/2016-09-07.md

@ -1,245 +0,0 @@
# Node Foundation CTC Meeting 2016-09-07
## Links
* **Audio Recording**: TBP
* **GitHub Issue**: [#8425](https://github.com/nodejs/node/issues/8425)
* **Minutes Google Doc**: <https://docs.google.com/document/d/1GRgBC5Dv5luqlRc6egtxmkrQULJXa3M3CqGqWfoogV8>
* _Previous Minutes Google Doc_: <https://docs.google.com/document/d/1qYUOfiiytaZ0-YZVZ1NZX9O-4SE28QNooapOdcjlPqA>
## Present
* Anna Henningsen @addaleax (CTC)
* Bradley Meck @bmeck (observer/GoDaddy/TC39)
* Сковорода Никита Андреевич @ChALkeR (CTC)
* Evan Lucas @evanlucas (CTC)
* Jeremiah Senkpiel @Fishrock123 (CTC)
* Tracy Hinds @hackygolucky (observer/Node.js Foundation)
* Josh Gavant @joshgav (observer/Microsoft)
* Michael Dawson @mhdawson (CTC)
* Julien Gilli @misterdjules (CTC)
* Ali Ijaz Sheikh @ofrobots (CTC)
* Rod Vagg @rvagg (CTC)
* Seth Thompson @s3ththompson (observer/Google)
* Steven R Loomis @srl295 (observer/IBM/ICU)
* Myles Borins @TheAlphaNerd (CTC)
* Trevor Norris @trevnorris (CTC)
* Rich Trott @Trott (CTC)
## Standup
* Anna Henningsen @addaleax (CTC)
* Issues & PR review
* Bradley Meck @bmeck (observer/GoDaddy/TC39)
* Just emails around modules
* Сковорода Никита Андреевич @ChALkeR (CTC)
* Some private ecosystem things
* Evan Lucas @evanlucas (CTC)
* opened PR for adding back --harmony-proxies flag, not much else
* Jeremiah Senkpiel @Fishrock123 (CTC)
* Working on v6.6.0
* issue & PRs, Async_Wrap review, some Timers PRs.
* Fedor Indutny @indutny (CTC)
* Reviewing PRs & Fixing bugs (sorry for not joining you today)
* Josh Gavant @joshgav (observer/Microsoft)
* Issues and PRs
* Michael Dawson @mhdawson (CTC)
* Investigating and PRs to move AIX to green in CI
* Migration to new set of PPC machines
* Addition of linuxOne to nightlies
* Moved API work to nodejs/abi-stable-nodenodejs/abi-stable-node-addons-examples
* presentations for Node Interactive EU
* Brian White @mscdex (CTC)
* Worked on finding improvements in http code
* Commented on issues, reviewed PRs
* Ali Ijaz Sheikh @ofrobots (CTC)
* Wrangle some V8 backports.
* Looking at performance w/ new ignition interpreter
* Rod Vagg @rvagg (CTC)
* Raspberry Pi cluster hardware problems, blog post
* Seth Thompson @s3ththompson (observer/Google)
* V8 team working on Ignition interpreter and V8 Inspector migration
* Steven R Loomis @srl295 (observer/IBM/ICU)
* PRs.
* Myles Borins @TheAlphaNerd (CTC)
* Auditing commits for v4.x
* Modifying output of testrunner
* preparing for interactive EU
* Trevor Norris @trevnorris (CTC)
* AsyncHook (formerly known as AsyncWrap); update embedder API to improve performance
* Rich Trott @Trott (CTC)
* Backporting a few small commits to v4.x
* Updating Build and Onboarding docs based on contributor mentoring and onboarding activities
* A few test PRs designed to increase test coverage
## Agenda
Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting.
### nodejs/node
* src: add no-op for --harmony-proxies flag [#8395](https://github.com/nodejs/node/pull/8395)
### nodejs/node-eps
* AsyncWrap public API proposal [#18](https://github.com/nodejs/node-eps/pull/18)
## Previous Meeting Review
* Process for determining supported platforms [#8265](https://github.com/nodejs/node/issues/8265)
* Build WG will prepare initial list of supported platforms in their next meeting.
* Then CTC will review and decide next steps.
* child_process, win: fix shell spawn with AutoRun [#8063](https://github.com/nodejs/node/pull/8063)
* Remove from CTC agenda.
* @joshgav to check for opinions within Microsoft.
* Ask @joaocgreis in GitHub for more explanation.
* fs: undeprecate existsSync; use access instead of stat for performance [#7455](https://github.com/nodejs/node/pull/7455)
* @trott to ping nodejs/collaborators in that thread. If no response then [fix].
* doc: add Google Analytics tracking. [#6601](https://github.com/nodejs/node/pull/6601)
* Merge!
* Introduce staging branch for stable release streams [#6306](https://github.com/nodejs/node/issues/6306)
* Do this as proposed.
* Move ecosystem detection tool to nodejs org [#7935](https://github.com/nodejs/node/issues/7935)
* Prep repo for migration.
* Open issue in nodejs/tsc.
* AsyncWrap public API proposal [#18](https://github.com/nodejs/node-eps/pull/18)
* Trevor to update all code and ask for vote on specific item(s).
* CTC to review again once complete.
## Minutes
### src: add no-op for --harmony-proxies flag [#8395](https://github.com/nodejs/node/pull/8395)
We upgraded to V8 5.1 in v6.5. That removed several flags, notably the --harmony-* flags. Many in the ecosystem have hard-coded these flags and as a result are getting errors since v6.5.
@evanlucas added a PR to no-op those flags. There was quite a bit of resistance to that, as it implies that we apply semver semantics to experimental features.
@addaleax: Does anyone have concrete reason to not no-op these flags?
@trott: For clarity, do we mean to no-op them till the next semver-major release?
@addaleax: Yes.
@Fishrock123: This would only ever land in v6.
@evanlucas: Some feel this should be floated on V8.
@trevnorris: Could they?
@ofrobots: Trivial to do it, but this is on 5.1 which is an abandoned upstream.
@trevnorris: We were told we could re-open abandoned branches?
@ofrobots: That’s correct.
@? : Were the flags removed because their behavior is V8's default?
@ofrobots: Yes, support was already there but flags had not yet been removed.
@? : Other flags were removed too.
@addaleax: Main issue is the --harmony flags, I haven’t seen the other flags as issues.
@ofrobots: I’m supportive of adding no-ops for --harmony flags cause they break the ecosystem. Others no.
@Fishrock123: What about strong mode flags?
@ofrobots: Mainstream users are not likely to be using strong mode flags.
@ofrobots: The ones recommended as no-ops I agree should be added back as no-ops.
@rvagg: We can adopt a new policy if we want, for example state that when we upgrade V8 flags may change and you have to do feature detection to address that.
@addaleax: Seems to be that’s what some people want in comments, but it seems that it might not be what people expect.
@rvagg: Many flags unlikely to be used in real code, but some may be used in production code. Ones that are potentially usable in production code, sure.
@trevnorris: Let’s re-add the no-ops and see if people raise issues about the others.
It would be more pure to backport in V8, but I don’t see why floating it in Node would be an issue.
@addaleax: @bnoordhuis was strongly -1 on floating a patch on V8, but didn’t give a reason.
@misterdjules: what do we mean by floating a patch?
@trevnorris: we don’t even have to let these through to V8, just catch it ourselves.
@Fishrock123: That would be harder.
@ChALkeR: perhaps warn in runtime on unsupported flags for next major?
@rvagg: Colin and Ben had negative positions.
Is proposal to ask Ali to move forward in V8?
@addaleax: Not expecting a definite decision, hoping to hear from people who are -1. Would be happy if someone put together a PR with all the flags we want to no-op and discuss in next meeting if necessary.
@trev: How long to get a patch on the V8 branch?
@ofrobots: Probably not too long, dependent on me finding a half hour.
This will be a patch we float on our downstream of V8 5.1. We are the de facto owners of this branch now.
@rvagg: Open a PR, move discussion there, people with negatives can expand on them there.
**Next steps**:
* @ofrobots to float a patch on our branch of V8 5.1 and open a PR. Discussion to continue there.
* Keep on agenda for next week just in case.
### AsyncWrap public API proposal [node-eps#18](https://github.com/nodejs/node-eps/pull/18)
@trevnorris: EP is near 100% ready, only thing likely to change is the native C++ API but after doing testing and implementation it’s where it needs to be for all of the goals set for it.
@rvagg: We need to sign off on the EP. Can’t do that today, right?
@trevnorris: No, but EP is there. I’ve updated it with code, examples, stuff like that.
@rvagg: Will there be changes in node-eps#18 between now and next week?
@trevnorris: No, unless some major change comes in.
@trevnorris: No docs yet, Bradley has volunteered.
@rvagg: There will eventually be a discussion of backporting to V4.
@trevnorris: Discussion continues on promise side.
@rvagg: cause we don’t have insight into the microtask queue?
@trevnorris: Yes. It’s proceeding.
@seththompson: V8 team is interested in helping with this. Looks like async/await won’t make cut for v7, gives us more time to work on the right thing here.
**Next steps**:
* Everyone read [node-eps#18](https://github.com/nodejs/node-eps/pull/18).
* Vote next week on Node-EP.
* Open a PR for implementation in nodejs/node.
### Modules
@bmeck: There were several concerns about the rewritten EP for ES6 module compat. Note that we haven’t merged that yet, people are welcome to comment in that issue.
@rvagg: Those who are concerned should definitely get in touch with Bradley (@bmeck).
## Q/A on public channels
* Thanks for the heads-up on async/await.
## Upcoming Meetings
* CTC: 2016-09-14
* TSC: 2016-09-08
* Benchmarking: [Benchmarking#56](https://github.com/nodejs/benchmarking/issues/56)
* Build: 2016-09-20

153
doc/ctc-meetings/2016-09-14.md

@ -1,153 +0,0 @@
# Node Foundation CTC Meeting 2016-09-14
## Links
* **Audio Recording**: TBP
* **GitHub Issue**: [#8506](https://github.com/nodejs/node/issues/8506)
* **Minutes Google Doc**: <https://docs.google.com/document/d/1kW9wLdfojpIGbu3fQMrtr7S_RJFq8CWupoKnmtWw17Q>
* _Previous Minutes Google Doc_: <https://docs.google.com/document/d/1GRgBC5Dv5luqlRc6egtxmkrQULJXa3M3CqGqWfoogV8>
## Present
* Bradley Meck @bmeck (observer/GoDaddy/TC39)
* Сковорода Никита Андреевич @ChALkeR (CTC)
* Evan Lucas @evanlucas (CTC)
* Jeremiah Senkpiel @Fishrock123 (CTC)
* Josh Gavant @joshgav (observer/Microsoft)
* Julien Gilli @misterdjules (CTC)
* Brian White @mscdex (CTC)
* Jenn Turner @renrutnnej (observer/Node.js Foundation)
* Rod Vagg @rvagg (CTC)
* Seth Thompson @s3ththompson (observer/Google)
* Trevor Norris @trevnorris (CTC)
* Rich Trott @Trott (CTC)
## Standup
* Bradley Meck @bmeck (observer/GoDaddy/TC39)
* Synched up with more people about ES Modules
* Сковорода Никита Андреевич @ChALkeR (CTC)
* Mostly nothing this week.
* Evan Lucas @evanlucas (CTC)
* Commented on issues/prs
* Jeremiah Senkpiel @Fishrock123 (CTC)
* v6.6.0 Release WIP
* ES Modules discussions
* Misc PRs / Issues
* Async_Hooks review / Thinking
* Josh Gavant @joshgav (observer/Microsoft)
* Diag WG activity
* modules discussion
* Julien Gilli @misterdjules (CTC)
* Timers code reviews and investigating/fixing libuv bugs on SmartOS. Read Async Hooks EP.
* Brian White @mscdex (CTC)
* Investigated UDP performance again for the purposes of a JS DNS resolver. With a few tweaks/optimizations, we can at least achieve performance very close to c-ares.
* Reviewed PRs, commented on issues
* Jenn Turner @renrutnnej (observer/Node.js Foundation)
* Observing, no update.
* Rod Vagg @rvagg (CTC)
* Travel, administrative, board, TSC, meetings, yabba yabba
* Seth Thompson @s3ththompson (observer/Google)
* v8_inspector move to v8 is almost done, builds in tree now
* continued discussion on microtask queue inspection here: https://bugs.chromium.org/p/v8/issues/detail?id=4643
* Trevor Norris @trevnorris (CTC)
* async_hooks. submitted PR and updated EP.
* Rich Trott @Trott (CTC)
* Onboarded @not-an-aardvark (with @addaleax’s help), @imyller, and @gibfahn
* ESLint update (replaced a custom rule with a built-in), test PRs, doc PRs
* A burst of first-time-contributor PRs landed, woo hoo
## Agenda
Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting.
* AsyncWrap public API proposal [node-eps#18](https://github.com/nodejs/node-eps/pull/18)
## Previous Meeting Review
Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting.
* src: add no-op for --harmony-proxies flag [#8395](https://github.com/nodejs/node/pull/8395)
* @ofrobots to float a patch on our branch of V8 5.1 and open a PR. Discussion to continue there.
* Keep on agenda for next week just in case.
* AsyncWrap public API proposal [node-eps#18](https://github.com/nodejs/node-eps/pull/18)
* Everyone read [node-eps#18](https://github.com/nodejs/node-eps/pull/18).
* Vote next week on Node-EP.
* Open a PR for code in nodejs/node.
---
## Minutes
### AsyncWrap public API proposal [node-eps#18](https://github.com/nodejs/node-eps/pull/18)
PR: [#8531](https://github.com/nodejs/node/pull/8531)
@trott: move to vote on the EP. Anything to discuss first?
@rvagg: One thing Trevor adjusted since discussion - some desire to have hooks that execute on one execution branch. Trevor can describe.
@trevnorris: if you were to enable a hook, run an async op, then disable the hook, any ops that took place during time when it was enabled will continue to have hooks called for them even after it’s disabled.
This was okay, I could’ve managed it, but `nextTick` alone increases the amount of hooks to be processed 3x.
**Votes**
* Yes - 7 - @rvagg, @evanlucas, @Chalker, @Fishrock123, @trevnorris, @mscdex, @trott
* No - 0
* Abstain - 1 - @misterdjules
---
### Other
@Chalker: Perhaps we should discuss GitHub functionality changes, such as the review capability in the web interface.
@trott: Open a PR to discuss. It could make fixing up the commit message simpler.
---
## Q/A on public channels
Q: @williamkapke: Live CTC meeting in Austin? [tsc#137](https://github.com/nodejs/tsc/issues/137)
A: @rvagg: More people probably and a good time too.
Q: What’s the status of ES6 modules? What’s the team’s personal opinion on that?
@Fishrock123: Mostly kept up in Node-EP 002 and related PRs. Some of us and @bmeck will be going to TC39 meeting at end of Sept. and have materials prepared to discuss problems we’re facing.
@trott: My personal opinion is that I hope we can work with TC39 and get alterations such that we can avoid `.mjs` extension, but if that doesn’t happen the `.mjs` extension isn’t ideal but I do believe that it’s better than other options.
@rvagg: My personal opinion is that we are unfortunately trapped in a tough corner where TC39 has created a spec which has technical problems for Node and we’ve had difficulty getting them to hear our concerns. They’d like us to make changes on our side and that would be enough, but that’s quite complicated.
We have many users who like the idea of modules, but they’re actually transpiled versions and not implemented by browsers.
@trott: I’m optimistic that things will work out well. I have a lot of faith in Bradley, Jeremiah, et al.
@Fishrock123: No browser / VM has this fully implemented yet. V8 would have to implement it first and it definitely won’t be done for Node.js v7.
@bmeck: Chakra’s impl is basically done for `type=module` spec in the browser, but that would drastically change if we went to TC39 and they changed the behavior.
@Chalker: Edge has modules in a preview release.
@Fishrock123: That’s Chakra, yes.
@rvagg: There will be a talk at Node Interactive Austin by Bradley, you should attend there. (CTC call at the same time, we might need to think about whether to have CTC call that day.)
## Upcoming Meetings
* CTC: 2016-09-21
* TSC: 2016-09-22
* Build: 2016-09-20
* Diagnostics: 2016-09-21
* Benchmarking: 2016-09-21? [Benchmarking#56](https://github.com/nodejs/benchmarking/issues/56)
* LTS:
* Post-Mortem:
* API:

218
doc/ctc-meetings/2016-09-21.md

@ -1,218 +0,0 @@
# Node Foundation CTC Meeting 2016-09-21
## Links
* **Audio Recording**: TBP
* **GitHub Issue**: [#8656](https://github.com/nodejs/node/issues/8656)
* **Minutes Google Doc**: <https://docs.google.com/document/d/1-PS20PGCJQIi4_quBHqVgrQNJeJP10NH21wUelcMhfw>
* _Previous Minutes Google Doc_: <https://docs.google.com/document/d/1kW9wLdfojpIGbu3fQMrtr7S_RJFq8CWupoKnmtWw17Q>
## Present
* Anna Henningsen @addaleax (CTC)
* Сковорода Никита Андреевич @ChALkeR (CTC)
* Evan Lucas @evanlucas (CTC)
* Jeremiah Senkpiel @Fishrock123 (CTC)
* Fedor Indutny @indutny (CTC)
* James M Snell @jasnell (CTC)
* Michael Dawson @mhdawson (CTC)
* Brian White @mscdex (CTC)
* Ali Ijaz Sheikh @ofrobots (CTC)
* Myles Borins @TheAlphaNerd (CTC)
* Rich Trott @Trott (CTC)
* Steven R Loomis @srl295 (observer/IBM/ICU)
* Seth Thompson (observer/Google)
* Jenn Turner (observer/Node Foundation)
* Josh Gavant (observer/Microsoft)
## Standup
* Anna Henningsen @addaleax (CTC)
* Node Interactive EU
* In particular, Code & Learn
* Сковорода Никита Андреевич @ChALkeR (CTC)
* Filed some PRs regarding doc linting
* Some issue comments and PR reviews as usual
* Evan Lucas @evanlucas (CTC)
* Working on an EP for exposing is* methods from core
* Jeremiah Senkpiel @Fishrock123 (CTC)
* async_hooks review
* v6.6.0 release
* Fedor Indutny @indutny (CTC)
* PRs, regular/security issues, Node.js Interactive!
* James M Snell @jasnell (CTC)
* Node Interactive EU/Collab summit
* Reviewing PRs (primarily from the code n learn)
* Preparing v7.0.0-beta1 (built now!)
* Preparing for TC-39 meeting next week
* Continued work on HTTP/2 plan
* Michael Dawson @mhdawson (CTC)
* Node Interactive EU/Collaborators summit
* New PPC machines into CI
* Addition of LinuxOne and AIX to nightlies
* build WG meeting, benchmarking WG meeting
* Investigating an AIX issues
* Some work on ABI stable API
* Catching up on issues
* Brian White @mscdex (CTC)
* Performance testing for various things
* Submitted PRs to improve setImmediate() and setTimeout()/setInterval() performance
* Submitted alternative PR to fix the malloc(0) compatibility issue introduced in node v6.6.0
* Worked on other various potential optimizations in core
* Reviewed PRs, commented on issues
* Ali Ijaz Sheikh @ofrobots (CTC)
* Mostly busy with internal stuff; work with some inspector PRs; finishing up V8 guide.
* Myles Borins @TheAlphaNerd (CTC)
* Node Interactive EU / Collab Summit
* Work on new tap reporter
* Reviewing @ofrobots work on V8 guide
* LTS backporting work
* Rich Trott @Trott (CTC)
* Onboarded @ak239 and @eugeneo
* assorted test, tools, and doc PRs
* https://github.com/nodejs/node/pull/8572 (Malloc and Calloc with size 0) to fix https://github.com/nodejs/node/issues/8571 (node::PBKDF2() Out of Memory) to land imminently, please take a look
* looking at the recent uptick in test failures, trying to figure out ways to fix it systemically and avoid it from recurring
* CTC meeting time proposal: more work than you think, trust me
* Seth Thompson @s3ththompson (observer/Google)
* continued v8_inspector work
## Agenda
* deps: update V8 to 5.4 [node#8317](https://github.com/nodejs/node/pull/8317)
* Scheduling Meetings [ctc#14](https://github.com/nodejs/CTC/issues/14)
* Decide on what problem points for ES Modules we care about the most. [ctc#15](https://github.com/nodejs/CTC/issues/15)
## Previous Meeting Review
* AsyncWrap public API proposal [node-eps#18](https://github.com/nodejs/node-eps/pull/18)
* Merge.
## Minutes
@trott: removed the async_hooks EP from the agenda, if anybody has concerns, the place for that would be on Github, or if necessary the item can be put on the agenda again.
### deps: update V8 to 5.4 [#8317](https://github.com/nodejs/node/pull/8317)
@ofrobots: V8 5.4 is part of Chrome beta. Since we’re trying to release v7.x with V8 5.4 I think it would be best to land this in master now rather than close to release.
Traditionally we’ve only landed V8 once it goes stable, but in this particular instance I think it’s important cause of 7.0 and this beta lining up so closely.
@Fishrock123: Original reason why we only landed stable was because in io.js we were landing beta, but the V8 team warned us that things could change, and they did change.
Did these things change on the V8 end? How is this different than yesterday?
@ofrobots: Google is saying we shouldn’t *ship* a V8 beta. It’s in master so it can undergo testing, but we wouldn’t ship it. Things could change but it doesn’t matter cause it’s just in master, we’re not shipping it.
@Fishrock123: Do RC’s count as shipping this? Some people will expect not much breakage between RC and release.
@jasnell: We’ve had issues where things are broken in master and people complain cause it’s broken in master even if it doesn’t go to releases.
@ofrobots: Purpose of an RC is to say this is what we think we’re going to ship, intention is not to change. With V8, we’ll also have the intention not to change. If a bug is found which breaks the web and a change needs to happen then it would happen.
@Seth: We treat beta as an RC in that respect.
@myles: Re what @jasnell said about things on master, it’s about things landing on master which are experience breaking. We’ve already been testing with 5.4. We should just be ready to revert if there’s an experience-breaking problem.
@Fishrock123: Good arguments, but we’re changing what we’re doing where we took a particular stance because people had issues with it.
@jasnell: We took that stance before we had the improved release model, with LTS. Risk was much greater then than now.
@trott: Any other voices?
@jasnell: @Fishrock123 is this something you absolutely want to see?
@Fishrock123: If there’s a vote I’ll just abstain.
@trott: Seems we have consensus and don’t need to vote.
@Fishrock123: Might as well try it again and see if it works.
@jasnell: If anything comes up, V8 team please give us a heads up as early as possible.
@ofrobots: one change that’s going to happen, is that since Node is going to use V8 5.4, we’re going to get v8_inspector into v8 and out of separate deps folder. This will make build and maintenance easier for Node.
**Next steps**:
- Do this and keep a careful eye.
- Evaluate after this cycle and decide what to do in the future.
---
### Scheduling Meetings [ctc#14](https://github.com/nodejs/CTC/issues/14)
@trott: Raising for CTC awareness.
---
### Decide on what problem points for ES Modules we care about the most. [ctc#15](https://github.com/nodejs/CTC/issues/15)
@Fishrock123: Majority of problems we can see so far are in EP #002, also in CTC#15.
Bradley’s been at this for almost a year trying to get better support for us and nothing’s really moved from the spec end. I kind of doubt it will but would like to push in that direction.
Would be good to find out what the CTC and Collaborators care about. Focus on CTC cause it’s easier to get overall decision with a smaller group. There’s a lot to talk about.
Hard to know what opinion I should have.
@trott: Is the question: Assuming the spec does not change, what should we do?
@Fishrock123: If we want to push the spec to changing for better compatibility, what do we want to push? Pushing on everything would be basically rewriting the entire spec…
@jasnell: Another aspect of this, conversations with TC39 at multiple levels, not just technical but also process. Try to help TC39 understand and care about the issues. If there’s something to change, it’s something they should care about also.
@Fishrock123: Still comes back to this list of issues. What do we want to tackle the most?
TC39 meeting next week, a couple people are going to that, context around what CTC cares about would be helpful.
@jasnell: TC39 is 9/27-29. We should have a call just for CTC to make sure all are on same page beforehand.
@Fishrock123: While I agree with that, we still need a consensus from the CTC on where to focus. Do we care about loading modules, REPLs, wrapping modules.
@trott: Anything in particular?
@jasnell: All are breaking issues.
@Fishrock123: We don’t break modules, but if a module moves to ESM they could break downstream modules.
@joshgav: In particular cannot change modules after import, breaks mocks and APMs.
@Fishrock123: For example, `graceful-fs` might not work at all.
@jasnell: What are our goals to come away from TC39 meeting?
@Fishrock123:
* TC39 showing some amount of care for our problems.
* Communication of those problems and some cooperation.
* Look at delaying shipping dates so we don’t have a browser vendor war which exacerbates our problems.
@trott: Encourage everyone to read the issue carefully, ask a bunch of questions, know that date of TC39 meeting is coming and we need one clear set of priorities. Everyone that can have an informed opinion on this should educate themselves and participate.
@jasnell: Talked with some of the members of TC39. What they articulated is that not to expect sweeping changes be made just because we ask for them.
Instead describe why the current spec is a problem, and if there are aspects which are incorrect or can be improved, it’s on us to make those changes.
We can’t expect them to care. Ideally they’d care already. But we have to have a proposal - this is why the module spec is broken, in terms of “we can’t implement it and this is why.”
@thealphanerd: Conversations on Twitter, biggest sentiment from TC39 is that there are individuals who do care and want to work with us on it. If we approach with that narrative we’ll likely have more progress.
@jasnell: Definite sentiment that we should be able to make this work, just a matter of making the right case.
---
## Q/A on public channels
None.
## Upcoming Meetings
* CTC: 2016-09-28
* TSC: 2016-09-22
* Build:
* Diagnostics: 2016-09-28
* Benchmarking: 2016-09-21
* LTS:
* Post-Mortem:
* API:

303
doc/ctc-meetings/2016-09-28.md

@ -1,303 +0,0 @@
# Node Foundation CTC Meeting 2016-09-28
## Links
* **Audio Recording**: TBP
* **GitHub Issue**: [#8802](https://github.com/nodejs/node/issues/8802)
* **Minutes Google Doc**: <https://docs.google.com/document/d/1ZsLMM29guCBPGh7KhuhZEq6YQCKybiTfTUIXajTBalM/>
* _Previous Minutes Google Doc_: <https://docs.google.com/document/d/1-PS20PGCJQIi4_quBHqVgrQNJeJP10NH21wUelcMhfw>
## Present
* Anna Henningsen @addaleax (CTC)
* Сковорода Никита Андреевич @ChALkeR (CTC)
* Colin Ihrig @cjihrig (CTC)
* Evan Lucas @evanlucas (CTC)
* Jeremiah Senkpiel @Fishrock123 (CTC)
* Tracy Hinds @hackygolucky (observer/Node.js Foundation)
* Josh Gavant @joshgav (observer/Microsoft)
* Michael Dawson @mhdawson (CTC)
* Ali Ijaz Sheikh @ofrobots (CTC)
* Jenn Turner @renrutnnej (observer/Node.js Foundation)
* Rod Vagg @rvagg (CTC)
* Seth Thompson @s3ththompson (observer/Google)
* Myles Borins @TheAlphaNerd (CTC)
* Trevor Norris @trevnorris (CTC)
* Rich Trott @Trott (CTC)
## Standup
* Anna Henningsen @addaleax (CTC)
* The usual, issues and PR reviews
* Сковорода Никита Андреевич @ChALkeR (CTC)
* Some issue and PR comments and reviews as usual.
* Some more work on docs linting.
* Colin Ihrig @cjihrig (CTC)
* Reviewing issues and PRs.
* Evan Lucas @evanlucas (CTC)
* v6.7.0 release
* More work on types eps
* Jeremiah Senkpiel @Fishrock123 (CTC)
* Issue / PR Review … general stuff
* Working towards ES Modules prototype implementations with Chris Dickinson
* Tracy Hinds @hackygolucky (observer/Node.js Foundation)
* getting the Outreachy info on website
* Josh Gavant @joshgav (observer/Microsoft)
* helping bring in some new MS contributors
* scheduled diag meeting for next week
* Michael Dawson @mhdawson (CTC)
* Finishing off PPC migration
* Fixing AIX issues when building from node-private
* Some work on ABI-stable node
* Misc PR review/lands
* Keeping up with issues
* Post-mortem nodereport review
* Brian White @mscdex (CTC)
* Worked on various performance improvements in node core
* Reviewed PRs, commented on issues
* Ali Ijaz Sheikh @ofrobots (CTC)
* Looking at node+V8 (5.5) integration build failures that seem related to recent parser improvements
* Investigating performance with the new interpreter
* Working with @matthewloring on FFI
* Jenn Turner @renrutnnej (observer/Node.js Foundation)
* No update, just observing
* Rod Vagg @rvagg (CTC)
* Security releases, supposed to be on vacation
* Seth Thompson @s3ththompson (observer/Google)
* async/await landed in V8 Tip of Tree. on track to ship with V8 5.5
* expect a doc from V8 language team on promise hook API to allow microtask introspection in the near future
* Myles Borins @TheAlphaNerd (CTC)
* issue / pr review
* helping with security release
* backporting inspector
* auditing v4 backlog
* really have to get to that tap reporter
* coming up with outreachy mentor project
* Trevor Norris @trevnorris (CTC)
* AsyncHooks
* Rich Trott @Trott (CTC)
* mentoring more first-time contributors (via Node Todo)
* doc, test PRs
* ramping up a tiny bit on Build WG stuff, but just a tiny bit
## Agenda
Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting.
### nodejs/CTC
* Scheduling Meetings [#14](https://github.com/nodejs/CTC/issues/14)
### nodejs/node
* meta: update NODE_MODULE_VERSION to 51 [#8808](https://github.com/nodejs/node/pull/8808)
* General v7.0.0 / v6 LTS Planning / Discussion
## Previous Meeting Review
* deps: update V8 to 5.4 [#8317](https://github.com/nodejs/node/pull/8317)
* Scheduling Meetings [#14](https://github.com/nodejs/CTC/issues/14)
* Decide on what problem points for ES Modules we care about the most. [#15](https://github.com/nodejs/CTC/issues/15)
## Minutes
### Scheduling Meetings [ctc#14](https://github.com/nodejs/CTC/issues/14)
@trott: This is a status report. Initial proposal was to dive in and start rotating meetings. Some were on board, some were concerned. Nikita started Google spreadsheet to figure things out.
One proposal is to move back one hour (12pm Pacific) which would be a mild improvement for Ben and Nikita.
Input received from NA and EU but not Asia and Australia. Once we have that information we can figure out what might work.
---
### meta: update NODE_MODULE_VERSION to 51 [#8808](https://github.com/nodejs/node/pull/8808)
`process.versions.modules` == 48 for v6.7.0.
Set in build script, we bump this number for each semver-minor. We’d update to 49, but Electron has been bumping in between, so we need to go to 51.
@thealphanerd: Had a way to do this in the past, but never landed a version of V8 on master [before a release]. So those using master cannot rely on this check.
Proposal is to add this to master now and v7.x when released. But should we wait to bump till the actual release?
@rvagg: If you’re using master, it’s been a bit “buyer beware” in the past.
@thealphanerd: Node-pre-gyp uses the module version number to determine whether to pull the pre-built binary or to rebuild. So that’s causing problems.
@ofrobots: Is there a disadvantage to doing this now?
@rvagg: Doesn’t seem to be.
@joshgav: Any concern that we’d have to bump again at v7.x release?
@rvagg: We’ll just bump again.
@addaleax: We should watch what Electron is doing cause they pull in every V8 version.
@trevnorris: Could it happen that newer version of V8 has a lower module version number?
@trott: if module version mapped to V8 version we could always be in sync.
@ofrobots: Problem is that ABI is more than just V8. Also, we’re moving to a VM-neutral API/ABI in the future and that will remove the relationship to a V8 version.
@rvagg: We should coordinate with Electron and draw from the same pool of numbers.
@ofrobots: A good point for a bump would be when we bring a new V8 into master.
@rvagg: This would make testing those nightlies easier.
@trevnorris: Sounds to me that we can’t map reliably map a version of Node to a version of V8. So pulling from the same pool as Electron might be misleading to developers. If the number in Electron doesn’t match a Node version there would be a conflict.
@rvagg: People are tracking which module versions map to what, so they could follow this too.
@trevnorris: Maybe we can give Electron the minor numbers.
@rvagg: NW.js also had a similar issue.
@thealphanerd: Electron bumped to 5.1 in an ABI-breaking way, so we have two versions of Node ABIs out there, cause they needed to stay closer to Chromium.
@rvagg: They don’t need to keep up with the latest version of V8.
@thealphanerd: Let’s talk offline.
@rvagg: Back to GitHub? Or do we need to decide now?
@thealphanerd : PR has a lot of LGTMs, would like to see this land today or tomorrow so we can unbreak master.
@ofrobots: Two points - one, what to do now; two, what to do going forward?
Ali and Myles will work on a policy going forward.
@rvagg: Might belong in LTS repo as we’ve been doing a lot of versioning stuff there.
**Next steps**:
* If there are objections raise them in the issue, otherwise ready to merge.
---
### General v7.0.0 / v6 LTS Planning / Discussion
@Fishrock123: Make sure all are in the loop.
Throw v0.10 in too since it’s end of life at end of October.
@rvagg: LTS map says *first* of October. Some people expect that cause the docs say that.
@Fishrock123: We discussed keeping it alive till end of December like v0.12, cause that’s when OpenSSL is EOL’ed.
@mhdawson: If the doc says Oct 1 what’s the downside to sticking with that?
@rvagg: We may have communicated Oct 31 through some channels, so some people may expect that.
Or perhaps when v7.x is first released.
Having said that, it’s been >2 years, so people have had time to migrate.
@rvagg: Originally 0.12 was slated for EOL in April 2017, we moved it back because of the OpenSSL issue.
@Fishrock123: Official LTS policy is target date is when the next release/LTS is cut. That’s usually midway through month.
@rvagg: Push to LTS WG to resolve ASAP.
@rvagg: James pushing another beta later this week or early next week.
@Fishrock123: v7.x is now on semver-major freeze.
@rvagg: There are some semver-major commits in master which aren’t in v7 release.
@Fishrock123: Might still need to update? Might have been left out by James intentionally?
@thealphanerd: Not a ton of semver-major things on master. There are the V8 upgrades (patches), and a move of a method to fs/internal.
Big one is npm@4 coming through the pipeline 1-2 weeks before Node release, should we include that.
@rvagg: npm@3 had problems originally so we delayed. Should we do the same for npm@4?
@addaleax: I’d feel comfortable with landing it. Kat said they aren’t concerned if 4 is included now or not.
@Fishrock123: Things which are deprecated in v4 will still be deprecated (not removed) in v5, so we could bump all the way to v5 in a later release.
@rvagg: We don’t have to synchronize all these dates to one, we can be flexible if needed.
@thealphanerd: If we have a date other than late October it might be a good idea to offer a date.
@ofrobots: Tentatively Oct 18 is the target stable date for V8 5.4. As tentative as usual, not clear till the last moment. Low chance that V8 will be moving a lot around Oct 18. Haven’t seen this date slip by more than 1-2 days. Very low chance that V8 will destablizie us.
@thealphanerd: Oct 25 as a tentative date for v7.x?
@rvagg: Ali and Seth, what’s the risk of setting that date now?
@ofrobots: Close to Oct 18 I can highlight any potential risk.
@rvagg: Let’s say that - 25th is tentative date, we’ll communicate if there’s any change. Any objections? (No.)
That will also be the day we switch v6 to LTS.
@thealphanerd: Doing release of v6 LTS earlier might be helpful so we have that out of the way for potential v7 issues.
@rvagg: Discussion on this will move to LTS WG. Join the LTS WG on Monday to discuss.
@thealphanerd: Could use someone to be responsible for v6 LTS, please volunteer.
@rvagg: It’s been helpful to have a single person for v4 LTS, but we need to find a model that scales in the future.
@Fishrock123: Would be helpful to schedule LTS a week earlier to avoid problems.
---
### Supported platforms proposal from Build WG [#488](https://github.com/nodejs/build/issues/488)
Current proposal: <https://github.com/nodejs/build/issues/488#issuecomment-250155697>
@trott should make a CTC agenda item next week?
@rvagg: Give input on that issue before it comes to CTC. Build WG must review and sign off on as well.
@rvagg: Some discussion about tiers, this affects OS vendors.
---
### Other
@thealphanerd: Node.js is going to be working with Outreachy project to help people from underrepresented groups get involved.
We need projects for these people to work on in 3 months. If you can think of good parts of the project to assign… would love to hear your suggestions.
@rvagg: GitHub thread?
@hackygolucky: I’ll create a new one and ping @nodejs/collaborators.
@rvagg: Are we getting a satisfactory response on the call for mentors?
@hackygolucky: 5 primary mentors and a number of supplementals. 4 sponsors, which means we can accept 4 mentees.
@rvagg: If someone wants to be a supplemental is that still open?
@hackygolucky: Thread is still open: https://github.com/nodejs/education/issues/7
---
## Q/A on public channels
None.
---
## Upcoming Meetings
* CTC: 2016-10-05
* TSC: 2016-10-06
* Build: 2016-10-11
* Diagnostics: 2016-10-05, 12pm Pacific
* Benchmarking:
* LTS: 2016-10-03
* Post-Mortem:
* API:

312
doc/ctc-meetings/2016-10-05.md

@ -1,312 +0,0 @@
# Node Foundation CTC Meeting 2016-10-05
## Links
* **Audio Recording**: TBP
* **GitHub Issue**: [#8915](https://github.com/nodejs/node/issues/8915)
* **Minutes Google Doc**: <https://docs.google.com/document/d/1ZsLMM29guCBPGh7KhuhZEq6YQCKybiTfTUIXajTBalM/>
* _Previous Minutes Google Doc_: <https://docs.google.com/document/d/1-PS20PGCJQIi4_quBHqVgrQNJeJP10NH21wUelcMhfw>
## Present
* Anna Henningsen @addaleax (CTC)
* Bradley Meck @bmeck (observer/GoDaddy/TC39)
* Colin Ihrig @cjihrig (CTC)
* Evan Lucas @evanlucas (CTC)
* Jeremiah Senkpiel @Fishrock123 (CTC)
* Tracy Hinds @hackygolucky (observer/Node.js Foundation)
* Michael Dawson @mhdawson (CTC)
* Julien Gilli @misterdjules (CTC)
* Mikeal Rogers @mikeal (observer/Node.js Foundation)
* Jenn Turner @renrutnnej (observer/Node.js Foundation)
* Rod Vagg @rvagg (CTC)
* Seth Thompson @s3ththompson (observer/Google)
* Myles Borins @TheAlphaNerd (CTC)
* Sakthipriyan Vairamani @thefourtheye (observer)
* Trevor Norris @trevnorris (CTC)
* Rich Trott @Trott (CTC)
* Josh Gavant @joshgav (observer/Microsoft)
## Standup
* Anna Henningsen @addaleax (CTC)
* Nothing noteworthy
* Bradley Meck @bmeck (observer/GoDaddy/TC39)
* Went to TC39, got late linking and re-linking fully discussed
* Working on live named imports talks and spec changes
* Colin Ihrig @cjihrig (CTC)
* Reviewing of issues and PRs.
* Evan Lucas @evanlucas (CTC)
* Worked a little on improving the commit linter
* Submitted a PR improving process.nextTick perf by 10-20% in some cases
* Jeremiah Senkpiel @Fishrock123 (CTC)
* merged existsSync undeprecation
* other PRs & Issues
* Tracy Hinds @hackygolucky (observer/Node.js Foundation)
* Outreachy application drive, issue open in the CTC repo
* Met last week to talk about code & lean @ Austin event
* Michael Dawson @mhdawson (CTC)
* Miscellaneous PR review
* fix a v8 test issue
* ABI Stable API meeting, reviews, discussion
* Closed out PPC migration
* Julien Gilli @misterdjules (CTC)
* Investigated SmartOS-specific issues.
* Mikeal Rogers @mikeal (observer/Node.js Foundation)
* Working on new budget for 2017 for the NF
* @ TC39 last week, very productive, looking for a way to be involved longer-term
* Brian White @mscdex (CTC)
* Continued work on various optimizations in core
* Submitted a few misc. cleanup PRs
* Reviewed PRs, commented on issues
* Jenn Turner @renrutnnej (observer/Node.js Foundation)
* No update, observing
* Rod Vagg @rvagg (CTC)
* Little build of build, little bit of LTS, little bit of NF work
* Seth Thompson @s3ththompson (observer/Google)
* async await on track to ship
* V8 inspector work ongoing
* Steven R Loomis @srl295 (observer/IBM/ICU)
* Regrets for today (and out next week) - ICU 58 will be out in a couple of weeks and will have an updated PR at that time…
* Myles Borins @TheAlphaNerd (CTC)
* v4.x backporting
* define outreachy project
* fix regressions in citgm
* work on new communication plan for LTS dates
* Sakthipriyan Vairamani @thefourtheye (observer)
* was sick for much of the week, so not much to report
* Trevor Norris @trevnorris (CTC)
* Fix performance regressions from async hooks
* Almost finished bringing PR compliant with EP. Soon tests and proper API documentation will follow.
* Engaged with the V8 team regarding the MicrotaskQueue API (https://bugs.chromium.org/p/v8/issues/detail?id=4643#c19)
* Rich Trott @Trott (CTC)
* CTC meeting rotation proposal
* 2FA for Collaborators
* miscellaneous issue tracker/commit activity
* Josh Gavant @joshgav (observer)
* time away
* diagnostics WG meeting
## Agenda
Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting.
### nodejs/node
* doc: add supported platforms list [#8922](https://github.com/nodejs/node/pull/8922)
* Intl: Consider deprecating Intl.v8BreakIterator [#8865](https://github.com/nodejs/node/issues/8865)
* net: multiple listen() events fail silently [#8419](https://github.com/nodejs/node/pull/8419)
### nodejs/CTC
* Scheduling Meetings [#14](https://github.com/nodejs/CTC/issues/14)
## Previous Meeting Review
* Scheduling Meetings [#14](https://github.com/nodejs/CTC/issues/14)
* meta: update NODE_MODULE_VERSION to 51 [#8808](https://github.com/nodejs/node/pull/8808)
* If there are objections raise them in the issue, otherwise ready to merge.
* General v7.0.0 / v6 LTS Planning / Discussion
## Minutes
### doc: add supported platforms list [#8922](https://github.com/nodejs/node/pull/8922)
@johanbergstrom put this together in collaboration with libuv and v8 teams.
@rvagg: Has everyone reviewed that would like to?
We rely on a few dependencies that make us who we are — most importantly V8 and libuv. We therefore need to adopt their supported platforms and potentially add to their lists based on test and/or release coverage.
@trott: Do we mean that we support whatever they support?
@Fishrock123: Could be clarified. Intent is that we must start with what they offer and anything additional falls to us (Node).
@rvagg: Our supported platform list is narrower than that of libuv and v8.
@?: It should say we’re a subset due to the constraints.
@rvagg: Removing that might be the way to go.
Any objections to list as it stands?
Applies to v6, probably the same for v7. Will need to be changed for v4.
If there are concerns, raise in issue.
**Next steps**:
* Raise any concerns in issue.
---
### Intl: Consider deprecating Intl.v8BreakIterator [#8865](https://github.com/nodejs/node/issues/8865)
Want to move to a different API: `Intl.Segmentor`, so want to deprecate this one.
@mikeal: We need to discourage community from using this API so we can move to a more standards-compliant implementation.
@rvagg: We expose this API because V8 exposes it.
@bmeck: APIs exposed by V8 can be removed…
@rvagg: New API is before TC-39, could take a while. Also, what is the timeframe for removal?
Is it possible this will be removed in 5.5 or 5.6, which may land in Node v7.x, in which case it would be a breaking change we’d have to polyfill.
Or will it be removed later and we can include it in Node v8.x.
@mikeal: V8 (Daniel) wants to remove this as soon as possible, but depends on TC-39.
@bmeck: Also some small percentage of web uses this so not able to completely remove yet anyway.
@seththompson: We wait till stage 3 at TC-39 to implement. As far as removing v8BreakIterator, we don’t necessarily rely on usage.
Will investigate this further with Daniel.
@rvagg: No problem with removing it, but need a signal as to when it will be removed.
@seththompson: Dan is out of office through next week.
**Next steps**:
* Continue discussion in GitHub.
---
### net: multiple listen() events fail silently [#8419](https://github.com/nodejs/node/pull/8419)
see also: <https://github.com/nodejs/node/pull/8294>
@jasnell added this item, would be a semver-major change, can it be landed in v7.
@rvagg: Adds error message when `.listen()` is called twice, EADDRINUSE.
@addaleax: (#8294)[https://github.com/nodejs/node/pull/8294] documented that .listen() twice restarts the server. Does that conflict with this?
@Fishrock123: When `close()` is called it resets the listen listener to `false`.
@rvagg: Is this the only way to close?
@addaleax: Might be…
@rvagg: Will keep on agenda for James to discuss.
@Fishrock123: Is anyone opposed to this?
@evanlucas: Have we tested against the ecosystem?
No, but it’s a poor usage anyway.
@trott: delay until next week when James is here.
@trevnorris: If you run this twice on the same server object, it overwrites the `_handle` property, orphaning the original handle.
@mhdawson: Do they get a new handle to use?
@trott: Put this into the issue.
**Next steps**:
* Discuss again next week.
---
### Scheduling Meetings [#14](https://github.com/nodejs/CTC/issues/14)
@trott: All possibilities are bad. Choosing the best of bad options. Hope to give proposed schedule a shot for 4 weeks and then evaluate. Or should we shoot this down and move on?
@rvagg: To start next week, Oct 12?
@trott: Yes.
@rvagg: Any objections to next week: UTC 4:00pm, US Pacific 9am, US East 12 noon.
Better for Europe and India.
No.
Next steps:
* Do next week at new time.
---
### General v7.0.0 / v6 LTS Planning / Discussion
LTS group agreed to put out v6 LTS week of 10/17.
Week after would be v7 final.
@thealphanerd: We should do a release the week before v6 LTS to include all semver-minor changes we want in.
@Fishrock123 will manage this release next week (10/10).
@rvagg will manage v6 LTS the week after (10/17).
@rvagg: What is status on V8 5.4 for 10/18?
@seththompson: @ofrobots to confirm, no known problems.
@rvagg: Still looking for someone to handle backports and releases for v6 LTS.
@Fishrock123: We could switch Myles to v6 and someone else can pick up v4.
@thealphanerd: As long as v4 is still “active” we have to go through everything. Some discussion of how to automate process.
There will be more backports to v6, but also that stuff will be a lot clearer, if it can be backported.
Would be good to come up with a better process for how things end up in staging. Instead of getting everything in there in the last minute.
@Fishrock123: I disagree that if v4 is active it needs to have the same amount of activity all the way through. There has been an understanding that it would get more and more difficult to backport features, focus only on backporting security fixes.
@thealphanerd: I found non-trivial number of items which would’ve been missed by automation.
I’m a little bit uncomfortable with not auditing everything. Things that would get missed are more important than they sometimes seem.
Myles, Evan, and Jeremiah to discuss tooling to help make auditing less work.
@rvagg: Need to resolve Intl.v8BreakIterator for v7 - if we need to deprecate or remove it would be good to do so now.
@SethThompson: Plan is to not deprecate anything until Intl.Segmentor reaches more conclusiveness in TC-39. But team would be fine if Node deprecates sooner.
Current open issues for v7: https://github.com/nodejs/node/milestone/15
@rvagg: We won’t have OpenSSL 1.1.0 in Node in the near future, but it may be possible to compile against it. This isn’t a blocker for v7, doesn’t require semver-major.
@rvagg: Should we ship another version of 0.10 with npm updated to include updated license? Comment in LTS WG.
---
## Q/A on public channels
Alex: Can we get a comment on stability of v6 at this point?
@rvagg: We’ll have a standard v6 release next Tuesday, and the following Tuesday we’ll drop to LTS and stability push will start. Expect it to be as stable as the v4 releases.
If you’re planning to move to v6 LTS, it’s worth testing now.
@Fishrock123: Not many new features in next week’s v6.x.x release. Some regressions early in v6 lifecycle, none now.
@evanlucas: Regression in inspector.
@rvagg: Inspector is still marked experimental for now. That may change in the v6 lifetime. But for now it shouldn’t be treated as stable as the other features.
---
## Upcoming Meetings
* CTC: 2016-10-12, 9am Pacific
* TSC: 2016-10-06, 1pm Pacific
* Build: 2016-10-11
* Diagnostics: first week of November
* Benchmarking:
* LTS: 2016-10-17
* Post-Mortem:
* API:

157
doc/ctc-meetings/2016-10-12.md

@ -1,157 +0,0 @@
# Node Foundation CTC Meeting 2016-10-12
## Links
* **Audio Recording**: TBP
* **GitHub Issue**: [#9020](https://github.com/nodejs/node/issues/9020)
* **Minutes Google Doc**: <https://docs.google.com/document/d/16l9D_OvAkeG6JoM_HRomHcFl--FTB61quvIWo9QfsVw>
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/1qRJiogKTWvxiHQ3S16MIR7BlynbXZPjqWwPScUSI2Rg>_
## Present
* Сковорода Никита Андреевич @ChALkeR (CTC)
* Colin Ihrig @cjihrig (CTC)
* Evan Lucas @evanlucas (CTC)
* Jeremiah Senkpiel @Fishrock123 (CTC)
* Michael Dawson @mhdawson (CTC)
* Brian White @mscdex (CTC)
* Ali Ijaz Sheikh @ofrobots (CTC)
* Shigeki Ohtsu @shigeki (CTC)
* Sakthipriyan Vairamani @thefourtheye (observer)
* Trevor Norris @trevnorris (CTC)
* Rich Trott @Trott (CTC)
## Standup
* Сковорода Никита Андреевич @ChALkeR (CTC)
* Nothing worth mentioning.
I was busy for the last week, catching up now.
* Colin Ihrig @cjihrig (CTC)
* Issue and PR review. A few PRs for tests.
* Evan Lucas @evanlucas (CTC)
* Opened a few PRs
* Some issue/pr review
* Wrote Chrome extension to make generating review metadata easier
* Jeremiah Senkpiel @Fishrock123 (CTC)
* misc PRs / issues
* working with the ChakraCore team on ES Modules
* v6.8.0 Release
* Michael Dawson @mhdawson (CTC)
* Misc review + land
* Back to working on adding nightly code coverage build
* ABI stable API PoC
* Keeping up to date on issues
* Brian White @mscdex (CTC)
* Worked on improved string encoding/decoding performance
* Reviewed PRs, commented on issues
* Ali Ijaz Sheikh @ofrobots (CTC)
* Travelling last week so not too much
* Shigeki Ohtsu @shigeki (CTC)
* Review some PR and issues related to crypto.
* Sakthipriyan Vairamani @thefourtheye (observer)
* catching up
* reviewing PRs and commenting
* Trevor Norris (CTC)
* Finishing up implementing parentId for async hooks
* Rich Trott @Trott (CTC)
* Issue and PR review
* governance discussions/issues
* Outreachy mentoring prep/work with applicants
## Agenda
Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting.
### nodejs/node
* governance: expand use of CTC issue tracker [#8945](https://github.com/nodejs/node/pull/8945)
* doc: add supported platforms list [#8922](https://github.com/nodejs/node/pull/8922)
* net: multiple listen() events fail silently [#8419](https://github.com/nodejs/node/pull/8419)
### nodejs/TSC
* Consider folding TSC into CTC [#146](https://github.com/nodejs/TSC/issues/146)
## Previous Meeting Review
### nodejs/node
* doc: add supported platforms list [#8922](https://github.com/nodejs/node/pull/8922)
* approved last week, if any objections comment now
on issue
* Intl: Consider deprecating Intl.v8BreakIterator [#8865](https://github.com/nodejs/node/issues/8865)
* now closed so resolved
* net: multiple listen() events fail silently [#8419](https://github.com/nodejs/node/pull/8419)
* back on agenda for this week
### nodejs/CTC
* Scheduling Meetings [#14](https://github.com/nodejs/CTC/issues/14)
* resolved, new meeting schedule set for next month.
## Minutes
### governance: expand use of CTC issue tracker [#8945](https://github.com/nodejs/node/pull/8945)
* don't want to change decision making process without
putting through current process.
* ctc-review label would be useful. For issues we need to
come to consensus but that we don't need to bring to meeting.
Still good to open issues in CTC repo.
* Comment from @thefourtheye that section on consensus
seeking model could use some clarification. Rich -> likely
out of scope for this change.
* This only applies to issues that don't need a vote, votes
mostly required when consensus cannot be achieved.
* Please add your comments or LTGM to the issue.
### doc: add supported platforms list [#8922](https://github.com/nodejs/node/pull/8922)
* discussed last week and input provided by CTC.
* removed from CTC-agenda.
### net: multiple listen() events fail silently [#8419](https://github.com/nodejs/node/pull/8419)
* latest discussion in issue still around if there is
any other way to close socket.
* you will already get errors if you listen twice.
* Some discussion, but missing proponents so discussion
back into github issue.
* If you object to it going into 7 (even though semver major)
make sure to comment.
### Consider folding TSC into CTC [#146](https://github.com/nodejs/TSC/issues/146)
* Already discussed in TSC, here to discuss with those not in CTC.
* no strong opinions voiced beyond what is in issue.
* comments that we have gotten questions as to
why we have 2 bodies.
### General v7.0.0 / v6 LTS Planning / Discussion
* 2 weeks out from V7.0 - Jerimiah handling this one.
* 6 days from LTS release - Rodd handling this one.
* v6 Current release should go out today.
### http: improve invalid character in header error message [9010](https://github.com/nodejs/node/pull/9010)
* asked if this could go into 7, some discussion, take
ongoing discussion back to github
## Q/A on public channels
## Upcoming Meetings
* CTC: 2016-10-19, 1pm Pacific
* TSC: 2016-10-13, 1pm Pacific
* Build: 2016-10-11
* Diagnostics: first week of November
* Benchmarking:
* LTS: 2016-10-17
* Post-Mortem:
* API:

202
doc/ctc-meetings/2016-10-19.md

@ -1,202 +0,0 @@
# Node Foundation CTC Meeting 2016-10-19
## Links
* **Audio Recording**: TBP
* **GitHub Issue**: [#9143](https://github.com/nodejs/node/issues/9143)
* **Minutes Google Doc**: <https://docs.google.com/document/d/18rnF8IfO10aQ0gRRasH3zSuv397-lm_x1fX1FSGcV7E>
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/16l9D_OvAkeG6JoM_HRomHcFl--FTB61quvIWo9QfsVw>_
## Present
* Bradley Meck @bmeck (observer/GoDaddy/TC39)
* Colin Ihrig @cjihrig (CTC)
* Evan Lucas @evanlucas (CTC)
* James M Snell @jasnell (CTC)
* Josh Gavant @joshgav (observer/Microsoft)
* Michael Dawson @mhdawson (CTC)
* Julien Gilli @misterdjules (CTC)
* Mikeal Rogers @mikeal (observer/Node.js Foundation)
* Brian White @mscdex (CTC)
* Ali Ijaz Sheikh @ofrobots (CTC)
* Jenn Turner @renrutnnej (observer/Node.js Foundation)
* Steven R. Loomis @srl295 (observer)
* Sakthipriyan Vairamani @thefourtheye (observer)
* Trevor Norris @trevnorris (CTC)
* Rich Trott @Trott (CTC)
## Standup
* Bradley Meck @bmeck (observer/GoDaddy/TC39)
* Vacation, work on import changes for ES spec
* Colin Ihrig @cjihrig (CTC)
* Reviewed issues and PRs. Revisited an old PR.
* Evan Lucas @evanlucas (CTC)
* cut v6.8.1 release
* opened small doc PR
* issue/pr review
* James M Snell @jasnell (CTC)
* Preparing v7.0.0 release
* HTTP/2 implementation
* PRs
* Josh Gavant @joshgav (observer/Microsoft)
* PR’s to improve user experience with new debugger
* investigating how to integrate guides with API docs
* off this week
* Michael Dawson @mhdawson (CTC)
* couple days vacation
* Added code coverage nightly job and PR for doc
* misc issue review/comment/lands
* Some Abi stable node discussion/work
* A number of benchmarking issues to look at
* Julien Gilli @misterdjules (CTC)
* nothing too significant
* Mikeal Rogers @mikeal (observer/Node.js Foundation)
* Putting together bugeting stuff
* Brian White @mscdex (CTC)
* Continued work on improving string encoding/decoding
performance.
* Commented on issues, reviewed PRs.
* Ali Ijaz Sheikh @ofrobots (CTC)
* Some V8 backport triage. Not much else notable.
* Jenn Turner @renrutnnej (observer/Node.js Foundation)
* Just observing, no update
* Steven R. Loomis @srl295 (observer)
* ICU 58 going GA end of week so will submit PR to update - [#7844](https://github.com/nodejs/node/issues/7844)
* Backported break iterator fix to v4.x [#9008](https://github.com/nodejs/node/pull/9008)
* Sakthipriyan Vairamani @thefourtheye (observer)
* mostly PR reviews
* Trevor Norris @trevnorris (CTC)
* Worked with Matt Loring, proposed promise hooks api is
sufficient combined with debugger API.
* Rich Trott @Trott (CTC)
* Outreachy
* flaky tests
* linting tools and rules
---
## Agenda
Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting.
### nodejs/node
* doc: add ctc-review label information [#9072](https://github.com/nodejs/node/pull/9072) @Trott
* http: improve invalid character in header error message [#9010](https://github.com/nodejs/node/pull/9010) @evanlucas
* net: multiple listen() events fail silently [#8419](https://github.com/nodejs/node/pull/8419) @jasnell
### nodejs/TSC
* Consider folding TSC into CTC [#146](https://github.com/nodejs/TSC/issues/146) @rvagg
---
## Previous Meeting Review
### nodejs/node
* governance: expand use of CTC issue tracker [#8945](https://github.com/nodejs/node/pull/8945)
* Finalize through GitHub discussions.
* Consider `ctc-review` label (#9072).
* doc: add supported platforms list [#8922](https://github.com/nodejs/node/pull/8922)
* Complete, remove from agenda.
* net: multiple listen() events fail silently [#8419](https://github.com/nodejs/node/pull/8419)
* Back to GitHub for further discussion.
### nodejs/TSC
* Consider folding TSC into CTC [#146](https://github.com/nodejs/TSC/issues/146)
---
## Minutes
### doc: add ctc-review label information [#9072](https://github.com/nodejs/node/pull/9072) @Trott
@trott: Has landed. If any objections speak now. Goal is more resolutions within tracker, less in meetings.
---
### http: improve invalid character in header error message [#9010](https://github.com/nodejs/node/pull/9010) @evanlucas
@evanlucas: Concerns about this leading to an information leak, because header name is displayed.
Would like to land this for v7. Would have to be merged today.
@trott: Question is if people are uncomfortable moving forward now before information from @Chalker is available.
@mhdawson: Seems there are already some hits (problems).
@evanlucas: Package `http-node` had problems, seems they copied `_http_outgoing.js`.
@evanlucas: Perhaps we can just add a debug message, that would not be semver-major.
@mhdawson: Seems better to do that than introduce a semver-major change this late.
@evanlucas: That seems fine, as long as we can get the needed info.
@trott: So land the debug message now, perhaps land standard output in v8.x.
**Next steps**:
* Create new PR with debug-based message, defer including in stderr/stdout till v8.x.
---
### net: multiple listen() events fail silently [#8419](https://github.com/nodejs/node/pull/8419) @jasnell
@jasnell: Question is whether to land in v7.x. If so please take it up today!
---
### Consider folding TSC into CTC [#146](https://github.com/nodejs/TSC/issues/146) @rvagg
@trott: Mainly to bring this to people’s attention, continue conversation in tracker.
---
### Info text in `--inspect` output [#8978](https://github.com/nodejs/node/pull/8978)
@joshgav: Should we land this for v7.x?
@trott: Is this a semver-major change?
@jasnell: No, especially cause this is an experimental feature.
@evanlucas: I’d prefer to wait till Chrome automatically lists Node.js targets via chrome://inspect, which is 55.
@ofrobots: No urgency to land this change now and it will make it harder to get started.
@mhdawson: Agreed, no urgency to land this before v7.x.
@joshgav: So I’ll update PR to include generic URL but not remove the chrome-devtools URL for now.
**Next steps**:
* Josh to update PR to still include chrome-devtools URL.
* Consider removing chrome-devtools URL when 55 is released (early December).
---
## Q/A on public channels
---
## Upcoming Meetings
* CTC: 2016-10-26, 9am Pacific
* TSC: 2016-10-20, 1pm Pacific
* Build: 2016-10-24 (?)
* Diagnostics: first week of November
* Benchmarking:
* LTS:
* Post-Mortem:
* API:

151
doc/ctc-meetings/2016-10-26.md

@ -1,151 +0,0 @@
# Node Foundation CTC Meeting 2016-10-26
## Links
* **Audio Recording**: TBP
* **GitHub Issue**:
[#9261](https://github.com/nodejs/node/issues/9261)
* **Minutes Google Doc**: <https://docs.google.com/document/d/1dUPFNyK8Yn1yWRAcXPY-mWM2KMWvOOB8Z5BH2s7RpJs>
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/18rnF8IfO10aQ0gRRasH3zSuv397-lm_x1fX1FSGcV7E>_
## Present
* Anna Henningsen @addaleax (CTC)
* Bradley Meck @bmeck (observer/GoDaddy/TC39)
* Ben Noordhuis @bnoordhuis (CTC)
* Сковорода Никита Андреевич @ChALkeR (CTC)
* Colin Ihrig @cjihrig (CTC)
* Evan Lucas @evanlucas (CTC)
* James M Snell @jasnell (CTC)
* Brian White @mscdex (CTC)
* Ali Ijaz Sheikh @ofrobots (CTC)
* Seth Thompson @s3ththompson (observer/Google)
* Shigeki Ohtsu @shigeki (CTC)
* Sakthipriyan Vairamani @thefourtheye (observer)
* Rich Trott @Trott (CTC)
## Standup
* Anna Henningsen @addaleax (CTC)
* Not much
* Bradley Meck @bmeck (observer/GoDaddy/TC39)
* Work on making inspector work w/ vm
* Minor talks w/ modules spec authors
* Ben Noordhuis @bnoordhuis (CTC)
* (Nothing reported.)
* Сковорода Никита Андреевич @ChALkeR (CTC)
* Rebuilt a new dataset from npm packages, some further work on the tooling
* Some issue/pr comments as usual
* Some ecosystem security stuff
* Colin Ihrig @cjihrig (CTC)
* Reviewing issues and PRs, opened a few PRs, libuv 1.10.0 update
* Evan Lucas @evanlucas (CTC)
* Working on getting libuv to use fsevents for file watching on OS X
* Opened small PR to fix a test that kept failing on freebsd
* James M Snell @jasnell (CTC)
* Getting v7.0.0 out the door
* PRs
* More work on HTTP/2
* Brian White @mscdex (CTC)
* Continued working on string encoding/decoding performance. Starting to see even more promising results.
* Reviewed PRs, commented on issues
* Ali Ijaz Sheikh @ofrobots (CTC)
* Not much
* Seth Thompson @s3ththompson (observer/Google)
* V8 5.5 beta shipped with async/await
* Shigeki Ohtsu @shigeki (CTC)
* Reviewed a few PR and made a security assessments of CVE-2016-8610 for Node-v0.10 and 0.12.
* Sakthipriyan Vairamani @thefourtheye (observer)
* Held an event to help people to get their first contribution into Node.js
* Looking at V8 code base
* Rich Trott @Trott (CTC)
* Outreachy, Node Todo, Node Interactive prep
* test and tools PRs
* usual PR review/commenting
---
## Agenda
Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting.
### nodejs/TSC
* Consider folding TSC into CTC [#146](https://github.com/nodejs/TSC/issues/146)
### nodejs/node
* Debugging: name every function
[#8913]https://github.com/nodejs/node/issues/8913
---
## Previous Meeting Review
Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting.
### nodejs/node
* doc: add ctc-review label information [#9072](https://github.com/nodejs/node/pull/9072) @Trott
* http: improve invalid character in header error message [#9010](https://github.com/nodejs/node/pull/9010) @evanlucas
* net: multiple listen() events fail silently [#8419](https://github.com/nodejs/node/pull/8419) @jasnell
### nodejs/TSC
* Consider folding TSC into CTC [#146](https://github.com/nodejs/TSC/issues/146) @rvagg
---
## Minutes
### Consider folding TSC into CTC
Rich: Defer until Rod is here and have the conversation in the issue tracker until then?
James: Makes sense. Also, TSC call is tomorrow so it can be discussed then.
### Debugging: name every function
Rich: It seemed like a good idea initially, but it is not clear if it is a good thing in all cases (some +, some -). Issue is marked as good first contribution which means lots of new contributors are coming in.
Myles wanted a quick resolution, but it is not clear there is a quick resolution. Someone needs to sit down and come up with a list of cases where it would be beneficial
Brian: Prototype functions?
Rich: That is a case where it doesn't add value but doesn't hurt either. There are other cases where it does remove information.
Sakthipriyan: One example was fs.readFileSync..
Brian: V8 may also be inferring names from a variable in cases when you do `let a = () => {...}`. Another case to take into consideration.
Rich: Move back to the issue tracker; remove 'good-first-contribution' label until we have documented what should/shouldn't be done. I can work with someone, or come up with documentation.
Floor: General agreement? Yes, general agreement.

143
doc/tsc-meetings/2015-05-27.md

@ -1,143 +0,0 @@
# Node Foundation TSC Meeting 2015-05-27
## Links
* **Audio Recording**: https://soundcloud.com/node-foundation/tsc-meeting-2015-05-27
* **Public YouTube feed**: http://www.youtube.com/watch?v=0DPfLxulsbQ
* **GitHub Issue**: https://github.com/nodejs/node-convergence-archive/issues/41
* **Original Minutes Google Doc**: https://docs.google.com/document/d/1-KlxiQGMsJFNJu3meok9e9XFsM39k_PMnQmY_9d_cy0
## Agenda
Extracted from **tsc-agenda** labelled issues and pull requests prior to meeting.
### nodejs/node-convergence-archive
* \[Converge\] timers: Avoid linear scan in `_unrefActive`. [#23](https://github.com/nodejs/node-convergence-archive/issues/23)
* \[Converge\] child_process argument type checking [#22](https://github.com/nodejs/node-convergence-archive/issues/22)
* \[Converge\] SSLv2/3 disable/enable related commits [#20](https://github.com/nodejs/node-convergence-archive/issues/20)
* doc: Add new working groups [#15](https://github.com/nodejs/node-convergence-archive/pull/15)
### nodejs/io.js
* Buffer implemented using Uint8Array [#1810](https://github.com/nodejs/io.js/issues/1810)
* \[Discussion\] FFI - Giving Buffer more low-level C functionality [#1750](https://github.com/nodejs/io.js/pull/1750)
* Chrome 43 released; time for V8 4.3! [#1735](https://github.com/nodejs/io.js/issues/1735)
* Deprecation Policy [#1704](https://github.com/nodejs/io.js/issues/1704)
* TSC needs to elect a board representative. [#1697](https://github.com/nodejs/io.js/issues/1697)
* V8 4.4 to remove indexed properties via external data [#1451](https://github.com/nodejs/io.js/issues/1451)
### joyent/node
## Present
* Alexis Campailla (TSC)
* Ben Noordhuis (TSC)
* Bert Belder (TSC)
* Brian White
* Chris Dickinson (TSC)
* Colin Ihrig (TSC)
* James M Snell (TSC)
* Jeremiah Senkpiel (TSC)
* Mikeal Rogers
* Michael Dawson (TSC)
* Mike Dolan (TSC)
* Rod Vagg (TSC)
* Shigeki Ohtsu
* Trevor Norris (TSC)
## Quick stand-up
* Rod: Working on combining the build, 3.0
* James: Working on repo convergence, triaging joyent/node issues, LTS policy drafting
* Shigeki: Investigating a slow tls test and SSL mitigations for a log jam attack.
* Jeremiah: Lots of little things
* Colin: Libuv work for os.homedir()
* Chris: Removing sys, checking breakage; fixing bug I introduced in persistent history
* Bert: Looking at issues
* Alexis: Working on combining the build, fixing windows issues
* Trevor: Working on the new Buffer impl using Uint8Array
* Michael: Traging joyent/node, spun up the benchmarking WG, looking into adding powerpc build machines
* Brian: Almost done the pure JS dns resolver, all tests are passing
* Ben:
- Make require faster
- Date.now() perf improvements
## Review of last meeting
* _Skipping_
## Minutes
### \[Converge\] timers: Avoid linear scan in `_unrefActive`. [#23](https://github.com/nodejs/node-convergence-archive/issues/23)
* James: conflicting approaches in both repos
* Ben: both are terrible under different workloads - do away with the code and start again
* Jeremiah: might have a go at it, working off an existing heap impl by Ben (ACTION)
* Bert: some problems with http - discussion happened about the implementation
* Chris: would be good to have Julien’s input since he was active on the joyent/node impl
### \[Converge\] child_process argument type checking [#22](https://github.com/nodejs/node-convergence-archive/issues/22)
* James: arg checking merged in 0.10 after the fork
* Discussion about why this wasn’t merged to io.js
* Defer back to GitHub discussion after no reason for not merging could be found on the call
### \[Converge\] SSLv2/3 disable/enable related commits [#20](https://github.com/nodejs/node-convergence-archive/issues/20)
* James: SSLv2/3 removed in io.js, merging these commits would involve reverting
* Jeremiah proposed 0.12 being the LTS for SSLv2/3 support
* Rod: are we happy killing this off?
* Michael: we don’t know how extensively it’s being used?
* James: pending research into that question we’ll leave this alone, come back if there’s a compelling reason to revert
### doc: Add new working groups [#15](https://github.com/nodejs/node-convergence-archive/pull/15)
* Michael: Benchmarking and Post Mortem Debugging working groups are ready and have started, i18n group needs a bit more work to get off the ground
* Group didn’t see any reason not to go forward with these groups, they have repos and can be in an “incubating” state for now
### Buffer implemented using Uint8Array [#1810](https://github.com/nodejs/io.js/issues/1810)
* Trevor: Buffer using Uint8Array is now working, all applicable tests pass, currently behind a flag:
* Trevor Questions:
- Are we going with v8 4.3 or 4.4?
- If we go v8 4.3, do we want to release behind a flag?
- we still want an upper kMaxlength Buffer size limit?
* Ben: Buffer size limit should be safe to remove
* Rod: 4.3 and 4.4 both contain major breakage for native addons
* Discussed if we would like to delay 3.0 until v8 4.4
* Rod: no appetite here for delaying a 3.0 with 4.3, take discussion on that back to GitHub
* Ben: suggested we release new Buffer impl with a flag to revert to old impl, Jeremiah seconded
* Discussed how hard it would be to land and review
* Fedor: how does it work with 32bit numbers?
* Trevor: It acts the same as before
### \[Discussion\] FFI - Giving Buffer more low-level C functionality [#1750](https://github.com/nodejs/io.js/pull/1750)
* Trevor: concerns about being able to write to buffers and execute arbitrary code
* Rod: concerned about changing the nature of what Node _is_ and the safety it exposes
* Ben suggested that we move this new work to an ffi module rather than hanging it off Buffer
- Group agreed to take this suggestion back to the issue for discussion
### Chrome 43 released; time for V8 4.3! [#1735](https://github.com/nodejs/io.js/issues/1735)
* Concerns about deps forcing semver-major, the C++ API changes are big enough to warrant this though
### Deprecation Policy [#1704](https://github.com/nodejs/io.js/issues/1704)
* Discussion dividing into two camps - conservative camp and those who want to test the size of the impact on the ecosystem
* Suggestion (Michael?) that we use LTS releases to determine when things get properly removed
* Discussed why we want a deprecation policy
### TSC needs to elect a board representative. [#1697](https://github.com/nodejs/io.js/issues/1697)
* Deferred till next meeting - need to nominate and vote someone in to this role and should discuss how we want to structure the role in terms of rotation
### V8 4.4 to remove indexed properties via external data [#1451](https://github.com/nodejs/io.js/issues/1451)
* Nothing to discuss, rolled up in to Buffer discussion earlier
## Next meeting
* June 3rd, 8PM UTC

166
doc/tsc-meetings/2015-06-03.md

@ -1,166 +0,0 @@
# Node.js Foundation TSC Meeting 2015-06-03
## Links
* **Audio Recording**: https://soundcloud.com/node-foundation/tsc-meeting-2015-06-03
* **GitHub Issue**: https://github.com/nodejs/node-convergence-archive/issues/47
* **Original Minutes Google Doc**: https://docs.google.com/document/d/1sTD0uryasBR15UBzEbJj3oHYtnuN9ZIqVxA2A_-N56E
## Agenda
Extracted from **tsc-agenda** labelled issues and pull requests prior to meeting.
### nodejs/io.js
* Add working group state per Project Lifecycle. [#1880](https://github.com/nodejs/io.js/pull/1880)
* Proposal: Split TSC agenda in to two meetings [#1879](https://github.com/nodejs/io.js/issues/1879)
* Chrome 43 released; time for V8 4.3! [#1735](https://github.com/nodejs/io.js/issues/1735)
* TSC needs to elect a board representative. [#1697](https://github.com/nodejs/io.js/issues/1697)
* Expose `deepEqual` and `deepStrictEqual` in `util`. #1172 [#1177](https://github.com/nodejs/io.js/pull/1177)
## Present
* Rod Vagg (TSC)
* Mikeal Rogers
* Shigeki Ohtsu (TSC)
* Chris Dickinson (TSC)
* Colin Ihrig (TSC)
* Julien Gilli (TSC)
* James Snell (TSC)
* Michael Dawson (TSC)
* Bert Belder (TSC)
* Fedor Indutny (TSC)
* Jeremiah Senkpiel (TSC)
* Domenic Denicola
* Alexis Campailla (TSC)
* Ben Noordhuis (TSC)
## Quick stand-up
* Rod: working on the build, looking into npm smoke-testing
* Mikeal: getting foundation legalities and officialities in order
* Shigeki: working on security issues, reviewing root cert update
* Chris: working on getting npm static analysis working [estoc](https://github.com/chrisdickinson/estoc)
* Colin: reviewing prs and issues, doing some libuv work (uv_os_homedir, which landed in libuv 1.6.0)
* Julien: vacation, nodejs.org downtime postmortem
* James: working on convergence, triaging joyent/node issues
* Michael: triaging some joyent/node issues, working on powerpc build and npm testing
* Bert: not much, looked at some issues, discussing with Saul if libuv should move into the Node Foundation
* Fedor: reviewed some pull requests and issues, working on some openssl mode
* Jeremiah: issues, convergence, `_unrefActive` timers work, looking at improving Ben’s binary heap implementation
* Domenic: vm fixes in v8 integrating patches
* Alexis: patch for timers firing early, CI convergence work - jenkins hackery
* Ben: reviewing pull requests, making libuv threadpool more scalable
* Brian: JS dns resolver
* Trevor: merged UInt8Array Buffer changes into the next branch, additional ArrayBuffer-related changes and fiddling
## Review of last meeting
### nodejs/node
* \[Converge\] timers: Avoid linear scan in `_unrefActive`. [#23](https://github.com/nodejs/node/issues/23)
* \[Converge\] child_process argument type checking [#22](https://github.com/nodejs/node/issues/22)
* \[Converge\] SSLv2/3 disable/enable related commits [#20](https://github.com/nodejs/node/issues/20)
* doc: Add new working groups [#15](https://github.com/nodejs/node/pull/15)
### nodejs/io.js
* Buffer implemented using Uint8Array [#1810](https://github.com/nodejs/io.js/issues/1810)
* \[Discussion\] FFI - Giving Buffer more low-level C functionality [#1750](https://github.com/nodejs/io.js/pull/1750)
* Chrome 43 released; time for V8 4.3! [#1735](https://github.com/nodejs/io.js/issues/1735)
* Deprecation Policy [#1704](https://github.com/nodejs/io.js/issues/1704)
* TSC needs to elect a board representative. [#1697](https://github.com/nodejs/io.js/issues/1697)
* V8 4.4 to remove indexed properties via external data [#1451](https://github.com/nodejs/io.js/issues/1451)
## Minutes
### Add working group state per Project Lifecycle. [#1880](https://github.com/nodejs/io.js/pull/1880)
* Mikeal: making working groups as “core” means they get to elect a TSC seat.
* Brief discussion about what WG’s should be considered “core” and get a TSC seat.
* Deferred to GitHub.
### Chrome 43 released; time for V8 4.3! [#1735](https://github.com/nodejs/io.js/issues/1735)
Domenic: things are ready to go. There’s some concern about double-breakage in 4.3 and 4.4.
Jeremiah: what about the maybe changes?
Domenic: the non-Maybe versions are still there, and haven’t been removed yet, either in 4.3 or 4.4 or even 4.5 (which isn’t finalized yet though).
Rod: blocker is whether the double-breakage is real, if not then we should move forward.
Domenic: there’s also the issue of some people in the thread advocating blocking a release on readying the ecosystem.
Rod: we shouldn’t be following the ecosystem and waiting for them to catch up before we release.
Mikeal: it’s more a matter of how we approach these things.
Michael: LTS should help this?
Mikeal: the problem is about major releases and the messaging - currently when people download them lots of stuff is broken.
Domenic called for a vote on a 3.0 release _assuming there is no double-breakage_.
Rod: I need to get the fix for node-gyp in place. Also we should see if we can get nvm to allow testing nightlies so that people can test them more easily (including on Travis).
Jeremiah: when I last talked to Jordan (@ljharb) he wanted to make sure that the mechanism we used for nightlies would also be the mechanism used in the converged project.
Mikeal: well that’s definitely true. So we should be good.
Trevor: do we have a way of measuring uptake?
Domenic/Rod: npm traffic is probably the best metric.
Rod calls for a vote.
Domenic: can we clarify whether we allow minor, covered-by-nan breakages between 4.3/3.0.0 and 4.4/4.0.0, or do we require no breakages at all?
Mikeal: is nan released?
Jeremiah: not yet; it is experimental and they don’t release until we merge next into master
Mikeal: that seems bad
(General agreement that we want nan to release first.)
Trevor: looking at nan they seem to be working to encapsulate changes all the way out to V8 4.6.
Bert: what was the problem with putting nan into core?
Rod/Ben: sometimes V8 makes big changes that cause breaking changes in nan. E.g. isolates, buffer changes, maybes. Until now it’s been just individual APIs, but the 4.3 and 4.4 change has been very big. nan’s promise is just that you can write against a single, possibly-changing API that will support multiple node versions.
### Expose `deepEqual` and `deepStrictEqual` in `util`. #1172 [#1177](https://github.com/nodejs/io.js/pull/1177)
Jeremiah: what do we want to expose from core, there’s pressure from some parts of the community for core to be more isomorphic and support a lot of browser stuff. This issue is specifically about exposing what’s already implemented.
Ben: why not pull it out of core and put it in npm? util has always been about utilities that core uses.
Rod: when you expose something you’re stuck with it forever, minimising surface area should be our goal because the more we have to officially support the slower our release cycle will be.
### Proposal: Split TSC agenda in to two meetings [#1879](https://github.com/nodejs/io.js/issues/1879)
Mikeal: the scope of the TSC responsibilities are too wide, making meeting times go to long. The suggestion is to split up in to “project” related issues and “core” related issues.
Rod: can there be a clear distinction between the issues?
Domenic: assuming nobody wanted to attend two meetings, would there be enough?
Mikeal: yes because there are lots of people that aren’t here who would be in the other group
Rod: I wonder about the timing, e.g. letting the foundation kickoff happen first; it feels a bit premature to split now.
Mikeal: it’s a little premature but that’s because we haven’t onboarded the core working groups to this meeting.
Bert: in favour of the proposal.
_Discussed the pros and cons and agreed to tentatively move forward with experimentation, time slot for the new “project” meeting would either be after the current meeting or the day after that meeting._
### TSC needs to elect a board representative. [#1697](https://github.com/nodejs/io.js/issues/1697)
***Call ended prematurely due to Uberconference difficulties***
## Next meeting
*

184
doc/tsc-meetings/2015-06-10.md

@ -1,184 +0,0 @@
# Node Foundation TSC Meeting 2015-06-10
## Links
* **Audio Recording**: https://soundcloud.com/node-foundation/tsc-meeting-2015-06-10
* **GitHub Issue**: https://github.com/nodejs/node-convergence-archive/issues/53
* **Original Minutes Google Doc**: https://docs.google.com/document/d/1cn7SKaKYUMYLBiQhE6HAAknnwPabKsYjpOuyQkVikW8
## Agenda
Extracted from **tsc-agenda** labelled issues and pull requests prior to meeting.
### nodejs/io.js
* Add working group state per Project Lifecycle. #1880
* Chrome 43 released; time for V8 4.3! #1735
* TSC needs to elect a board representative. #1697
### joyent/node
* Nominating new collaborators to this repository #25481
* Node should not automatically change rlimits #8704
* Re-purpose previous joyent/node TSC meeting as LTS working group
* Releases for logjam - expect new openssl version soon (possibly should be discussed in LTS working group instead)
## Minutes
### Present
* Shigeki Ohtsu (TSC)
* Colin Ihrig (TSC)
* Alexis Campailla (TSC)
* Bert Belder (TSC)
* Ben Noordhuis (TSC)
* Julien Gilli (TSC)
* Mikeal Rogers
* Michael Dawson (TSC)
* Domenic Denicola
* Brian White (TSC)
* Bradley Meck
* Trevor Norris (TSC)
### Quick review of the previous meeting
* **Bert**: Discussed adding WG for project life cycle. Don’t remember what the idea was.
* **Mikeal**: Need to merge the associated PR.
* **Bert**: Discussed upgrading V8 to 4.3. Some contention, much in favor of doing it. Issue is V8 is changing API in 4.3 and 4.4 again.
* **Trevor**: Biggest issue is nan 2.0 hadn’t come out yet. There would be a gap in time when no native module would work.
* **Bert**: Resolution was that we would try to get nan to update asap. If 4.4 wasn’t done yet we would not upgrade to 4.3 yet.
* **Bert**: Mikeal had proposed to split meeting in two different meetings: one technical, one non technical.
### Standup
* **Shigeki**: preparing for the next OpenSSL update.
* **Michael**: working on triaging issues, made sure V8 beta/stable build properly on PPC. Internally setup some build to build io.js next on PPC, so that we can hook up build machines asap.
* **Colin**: mostly just reviewed PRs and triaged issues.
* **Brian**: mostly triaging issues, looked at some PRs.
* **Julien**: triaged issues, reviewed PRs. Started documenting Node.js’ release process and CI platform. Also started to document breaking changes between v0.12 and the converged repo between io.js and Node.js.
* **Alexis**: investigations on native addon WG.
* **Bert**: not a lot of technical work. Working on libuv changes to make the multi isolate/workers stuff work. PR #396 in libuv.
* **Ben**: reviewed PRs.
* **Domenic**: some reviews and tried to gear up for 3.0.
* **Trevor**: Lot of reviewing and landing of PRs, prototype for lower-level JS API. Worked on async listeners API.
* **Bradley**: here for rlimits discussion on the agenda.
* **Mikeal**: launch of the foundation, getting the PR ready and working on nodeconf that starts tomorrow.
### Today’s agenda
#### Add working group state per Project Lifecycle
* **Mikeal**: pretty much resolved, we just need to close the PR.
#### Chrome 43 released; time for V8 4.3
* **Domenic**: not sure if there’s much progress on that. Haven’t seen news from nan.
* **Bert**: remove tsc-agenda, someone should put back the tag when there’s news.
#### TSC needs to elect a board representative.
* **Mikeal**: thought that we had a resolution, and Bert and Rod would both be on the board for a short time.
* **Bert**: see if that can stay that way in the long term. Any objection?
* **Michael**: have we approached other people from the foundation to see if that’s possible?
* **Bert**: haven’t reached out yet. Who is organizing these meetings?
* **Mikeal**: Mike Dolan.
* **Bert**: Will send an email to see if that’s feasible.
* **Michael**: what about voting?
* **Mikeal**: we would need to put down just one person who has voting rights.
* **Michael**: having two present in meetings, only one who has the vote is fine by me.
* **Bert**: I don’t expect to be any kind of contention, trademark is probably the only one I can think of now.
* **Mikeal**: It seems that people don’t have a good idea of what will be decided during these meetings, so maybe we can just flip a coin for this short period of time, and then when we know more of what’s discussed in these meetings we can have a vote.
* **Michael**: maybe have some sort of alternance between two people in the beginning?
* **Bert**: I think it would still be good to have one person who will always be there.
* **Bert**: proposed resolution: let’s both (Rod and I) be there and then we’ll reevaluate later.
#### Nominating new collaborators to this repository
See https://github.com/joyent/node/issues/25481.
Main question was: should we add nominated collaborators who are not io.js collaborators too the “collaborators” team in the nodejs organization too?
Decision was that it might be confusing at first, so onboarding of these collaborators will be done first in joyent/node only, but they will conceptually be Node.js collaborators (as in collaborators in the nodejs GitHub organization). Shortly after they will be added as io.js collaborators by people familiar with the onboarding process at io.js.
#### Node should not automatically change rlimits
* **Bradley**: summary is in node v0.10. Node respected soft ulimit for fds. Soft limit is recommended limit, second one called hard limit which is an enforced limit. By default, OSX has a very low soft limit, and that’s the reason why this patch landed. However when running programs, they usually don’t change rlimits, and we started seeing failures after the patch landed. Argument for the side for keeping the patch, you don’t hear people complaining about being out of file descriptors.
* **Michael**: did patch change only for OSX?
* **Bradley**: did for all platforms. Hard limit becomes soft, soft limit are erased.
* **Michael**: fix means you don’t see errors?
* **Bradley**: yes, but it has undesirable side effects. Traditionally when you limit resources, you set soft limits to what you want your process to be able to get. Node started to ignore those, so we started seeing things like fds leaks not being caught, etc.
* **Ben**: why wouldn’t you set the hard limit to the soft limit?
* **Bradley**: This patch completely erases your soft limit, can’t recover it. No option to use soft limits at this point. Cluster would want very high limit, workers would want lower limit. Using soft limit is usually how people do that. You can use hard limits, but once you do that you’re talking about absolute enforcement.
* **Bert**: proposal is to revert the patch?
* **Bradley**: couple options. Ideal option to me is to revert the patch. I would expect UNIX programs to leave my settings alone. I would at least expect an option to recover the soft limits. Having some way to pass settings via command line maybe?
* **Bradley**: either command line flag or environment variable. Problem with command line anything that spawns with something like fork would ignore it.
* **Bert**: actually happy that the patch landed. Just works solution seems better, I’ve seen so many problems in production. Two concerns: agree this is a bit weird that node changes limits of child processes. Would not be opposed to use an environment variable.
* **Bradley**: argument will come from sysadmins, not people not familiar with EMFILE and rlimits. Usually you see the EMFILE error, you request to someone to bump this limit and the problem is solved.
* **Trevor**: what if we added process.resetRlimits and when that process spawns it resets rlimits.
* **Bradley**: need to pass that to child processes still.
* **Trevor**: if using cluster, then that seems easy.
* **Bert**: Don’t like having globals for that kind of stuff, related to multi isolates. Maybe add as an option to child_process.spawn?
* **Trevor**: how would that help regarding multi isolates environments?
* **Bert**: Yeah, not suggesting to be able to set different limits per isolate. Ben any opinion?
* **Ben**: Resetting rlimits when we spawn new process would be fine. Don’t care about environment variable that would make node not touch rlimits.
* **Domenic**: Does node change system wide rlimits?
* **Bradley**: that depends on how the node process lifecycle.
* **Domenic**: Is there any way to ignore rlimits while not changing system wide rlimits?
* **Bradley**: it’s a per process setting. Want a way to keep limits to get warnings about file descriptors, and a way to recover limits in child processes. I can write a patch for that.
* **Ben**: Keep in mind you’ll probably need to update libuv in some way. Forking takes places in libuv.
* **Bert**: summary: node will restore rlimits on spawn.Other thing would be command line switch or environment variable.
* **Ben**: How are you going to use that? Are you using sandbox?
* **Bradley**: Not using sandbox. When I see EMFILE, I can set a warning that notifies me when things go crazy.
##### Resolution
* The current (rlimit-changing) behavior will be maintained.
* Node/libuv should restore the ulimit for the child processes it spawns.
* Support for leaving the ulimit untouched by setting an an environment variable will be added.
* Bradley Meck is going to create patches to node and libuv for this.
#### New OpenSSL version about to be released, with fixed for logjam
* **Michael**: will need a v0.10 and v0.12 release when OpenSSL release comes out.
#### Repurpose previous node.js TSC meeting as LTS WG meeting
* **Julien**: timing might not work for anyone.
* **Bert**: Rod pinged a bunch of people, haven’t seen a lot of response. Wyatt Preul is involved, you will probably want to reach out to him, Same for ofrobots.
* **Michael**: want to make sure that everyone is ok with merging LTS meeting with joyent/node TSC meeting.
* **Julien**: discussion ongoing here: https://github.com/nodejs/LTS/issues/6#issuecomment-109352447.
### Discussion items not on the agenda
#### 3.0 upgrade documentation
* **Trevor**: haven’t seen any doc on how to upgrade to 3.0. Should be put notes about breaking changes there, or somewhere else?
* **Domenic**: hard part is C++ side changes. Everything else should be handled by semver-major/minor labels.
### Rebasing on top of the 'next' branch (not on the agenda)
* **Trevor**: rebase of next on master is going to be fairly broken. Is there somebody who usually takes those merges?
* **Ben**: Not sure I understood.
* **Trevor**: Lots of fixes that went into 2.x will not merge cleanly in next. Some of the fixes are minor. Fix in zlib that uses kMaxLength.
* **Ben**: what’s the question?
* **Trevor**: wondering who’s responsible for the merge? Maybe I can help with that?
* **Ben**: most of the time I do that. I usually create a PR and ask people to give a quick sign off on it.
##### Action items
* Trevor will document C++ side changes.
#### Workers (multi-isolate) PR
* **Bert**: decided to take a look at the multi isolates patch. I know that Ben tried to review it and went half-way through.
* **Trevor**: tried twice now and haven’t managed to go all the way through.
* **Bert**: proposed solution is to just make sure it doesn’t break anything major, put it behind a flag and review it in more details later.
* **Trevor**: a lot of stylistic issues, and haven’t got any response.
* **Ben**: petka mentioned he’s quite busy at the moment. Maybe someone could address these comments?
* **Bert**: ping petka, maybe we can land it in small increments. Do we want it to be perfect before it lands?
* **Ben**: not comfortable landing code that hasn’t been reviewed.
* **Trevor**: nice thing is that there’s a lot of tests. Didn’t see anything invasive that would make things difficult later. One change that I don’t understand 100%. I would depend on someone else to give the OK.
* **Bert**: interesting and valuable change, it needs work to get landed.
## Next meeting
Will be held on June 17th, 1pm PST.

134
doc/tsc-meetings/2015-06-17.md

@ -1,134 +0,0 @@
# Node Foundation TSC Meeting 2015-06-17
## Links
* **Audio Recording**: https://soundcloud.com/node-foundation/tsc-meeting-2015-06-17
* **GitHub Issue**: https://github.com/nodejs/node-convergence-archive/issues/56
* **Original Minutes Google Doc**: https://docs.google.com/document/d/1d4mAJgm06rpPWLDqhZcxsRnKMrS92Ip4CW2akOyeIL4
## Agenda
Extracted from **tsc-agenda** labelled issues and pull requests prior to meeting.
### nodejs/node
* Create a security team [#48](https://github.com/nodejs/node-convergence-archive/issues/48)
### nodejs/io.js
* Nominating Shigeki Ohtsu @shigeki to the TC [#1501](https://github.com/nodejs/io.js/issues/1501)
* Nominating Brian White @mscdex to the TC [#1500](https://github.com/nodejs/io.js/issues/1500)
* on working with proposals from the API WG [#1993](https://github.com/nodejs/io.js/issues/1993)
* zlib: prevent uncaught exception in zlibBuffer [#1993](https://github.com/nodejs/io.js/issues/1811)
* Proposal: Release Process [#1997](https://github.com/nodejs/io.js/issues/1997)
### joyent/node
* Nominating new collaborators to this repository [#25481](https://github.com/joyent/node/issues/25481)
## Minutes
### Present
* Rod Vagg (TSC)
* Colin Ihrig (TSC)
* Chris Dickinson (TSC)
* Michael Dawson (TSC)
* Mikeal Rogers
* Steven R. Loomis (TSC)
* Bert Belder (TSC)
* Alexis Campailla (TSC)
* Julien Gilli (TSC)
* Shigeki Ohtsu
* Jeremiah Senkpiel (TSC)
* Brian White
* Trevor Norris (TSC)
* Domenic Denicola
* Fedor Indutny (TSC)
### Review of the previous meeting
* Add working group state per Project Lifecycle
* Chrome 43 released; time for V8 4.3
* TSC needs to elect a board representative.
* Nominating new collaborators to this repository
* Node should not automatically change rlimits
* New OpenSSL version about to be released, with fixed for logjam
* Repurpose previous node.js TSC meeting as LTS WG meeting
* 3.0 upgrade documentation
* Rebasing on top of the 'next' branch (not on the agenda)
* Workers PR from Petka
### Standup:
* Rod: build, productive work on improving the ci and build convergence, ci now does linting before running the tests, also improving the io.js make file so that less logic for releases is contained in jenkins
* Colin: reviewing issues and pr’s, landed a cluster patch to not use --debug_port on cluster workers by default
* Chris: NodeConf, got great feedback there. PR for code coverage incoming soon, spun up the docs WG.
* http://neversaw.us/scratch/node-coverage/ – code coverage
* https://github.com/nodejs/docs
* Michael: Reviewing OpenSSL changes for LogJam; PPC LE & BE work nearly complete, some OpenSSL blockers (EC related)--working towards including PPC in CI
* Mikeal: running NodeConf and writing up feedback & foundation work
* Steven: getting back on board
* Bert: libuv work for multi-worker on Windows (https://github.com/libuv/libuv/pull/396), found a potential libuv/Windows contributor at NodeConf, NF board meeting
* Alexis: Working on build & CI convergence with Rod, CI can now automatically decide what options to use for different node versions, and porting node-accept-pull-request CI job.
* Julien: time off, launching nodejs.org updates for NF launch, working on changes for 0.10/0.12 releases, onboarded two new collaborators for joyent/node - https://github.com/nodejs/LTS/wiki/Breaking-changes-between-v0.12-and-next-LTS-release
* Shigeki: Working on upgrading OpenSSL, the upgrade process is becoming much simpler, landed the CINNIC whitelist
* Jeremiah: NodeConf - brought back good feedback, helping spin up the Diversity WG, integrating timers heap impl, struggling with bugs
* Brian: not much, triage & PR review
* Trevor: reviewing, commenting, merging, PR to next branch allowing passing ArrayBuffers to Buffers constructor
* Domenic: reviewing, some work with Trevor, discussing release procedure
* Fedor: Reviewing issues(?), working on http/2 in node-spdy
### Nominating Shigeki Ohtsu @shigeki to the TC [#1501](https://github.com/nodejs/io.js/issues/1501)
### Nominating Brian White @mscdex to the TC [#1500](https://github.com/nodejs/io.js/issues/1500)
Called for a vote, got +1's for both candidates from each of: Chris, Rod, Bert, Colin, Trevor, Jeremiah, Julien, Michael, Alexis
### on working with proposals from the API WG [#1993](https://github.com/nodejs/io.js/issues/1993)
* Trevor: started discussions back in advisory board before io.js existed, large companies wanted “official Node.js compatibility” at both module and JS layer. Some dissenting voices in Joyent that prevented things proceeding. After io.js happened the formal discussion ended but informal discussion continued, e.g. in https://github.com/nodejs/nan/issues/349, aim at the C++ level is to reduce API turn-over. Companies involved have their own VMs and want to maintain them for their own purposes (e.g. Chakra, JVM).
* Trevor: interested in starting a WG or piggy-backing Addon API WG.
* Domenic: would like more clarity on what this thing could be, is it libuv.js? is it a VM abstraction layer?
* Bert: would be good to scope this work
* Trevor: there’s one interest group--concerned with binary addons and not having to ship new versions with each new Node release. Another interest group is concerned with something akin to a process.bindings abstraction layer so you could put the Node JS layer on top of whatever runtime chosen.
* Bert: standardising the process.bindings API might be easiest but standardising the C++ API has more beneifits because it solves the v8-upgrade-breaks-addons problem.
* Rod: https://github.com/nodejs/nan/issues/373 is an issue in NAN for organising a meeting for the various groups interested in exploring C++ API compatibility, specifically for addons.
### zlib: prevent uncaught exception in zlibBuffer [#1811](https://github.com/nodejs/io.js/issues/1811)
* Trevor: Issue #1811 is potentially CVE-worthy, it’s been fixed but what is the process for going forward with a CVE if necessary?
* Rod: security@nodejs.org has an expanded team and security@iojs.org redirects there as well. That team should be delegated to for discussion--if you have concerns then email them and let them be responsible for deciding how to proceed.
* ACTION: Trevor to email summary of potential security concern to security@nodejs.org for further discussion amongst that group. Potentially also backporting to 0.10 and 0.12.
### Proposal: Release Process [#1997](https://github.com/nodejs/io.js/issues/1997)
* Mikeal:
- next branch to be released on a more regular timeline
need to message to users that are on the “next” branch that there is a tradeoff between new V8 (features + perf) and being able to use native modules
- bring next to current, current to LTS
* Domenic:
- core of the proposal:
- pseudo-LTS
- maintain V8 version for ourselves
- don’t backport any breaking changes from master, only features and patches
- release this with name that implies “use this to work with native modules and features” ???? (CD - lost track here)
- active dev happens here
* Trevor: Naming is confusing; why isn’t it sufficient to say “this release is LTS”?
* Mikeal: We don’t want LTS to mean “this is stable”, we want it to mean “I can use this for five years”
* Trevor: But that’s the same thing, isn’t it?
* Rod: Using the term LTS is counterproductive (leave it to the LTS working group) – it distracts
* Trevor: one year span before [V8] is merged – that sounds like LTS
* Domenic: This is a new release channel/train
* Mikeal: We need “stable for a year” / “new features in V8, no native modules” / “stable for five years”
we stick with semver
(CD: Mikeal could you fill this out further?)
* Domenic: We don’t need to move away from semver for the next branch
Yearly releases pick a version that aligns
* Mikeal: don’t call it canary, get a codename – increment one, two, three or five over a year – when we merge into master we choose a new name
* CD: Could not capture entirety of discussion – moved a bit fast for me.
* Bert: there is no ideal answer here. Would like mikeal and domenic to continue discussion and come back with something to vote on.
## Next meeting
Next week, 2015-06-24

88
doc/tsc-meetings/2015-07-01.md

@ -1,88 +0,0 @@
# Node Foundation TSC Meeting 2015-07-01
## Links
* **Audio Recording**: https://soundcloud.com/node-foundation/tsc-meeting-2015-07-01
* **GitHub Issue**: https://github.com/nodejs/node-convergence-archive/issues/60
* **Original Minutes Google Doc**: https://docs.google.com/document/d/1TN3Ks0fC4ciY3jeS0VxXxXRkT_dq8-tfs-bWQqZGRoE
## Agenda
Extracted from **tsc-agenda** labelled issues and pull requests prior to meeting.
### nodejs/io.js
* Policy for PR blocking? [#2078](https://github.com/nodejs/io.js/issues/2078)
* International WG
* lts: strawman LTS cycle [lts#13](https://github.com/nodejs/LTS/pull/13) / Proposal: Release Process [#1997](https://github.com/nodejs/io.js/issues/1997)
## Minutes
### Present
* James Snell (TSC)
* Bert Belder (TSC)
* Steven Loomis (TSC)
* Chris Dickinson (TSC)
* Mikeal Rogers
* Trevor Norris (TSC)
* Brian White (TSC)
* Jeremiah Senkpiel (TSC)
### Review of the previous meeting
* discussion of stability for internal APIs [#2030](https://github.com/nodejs/io.js/issues/2030)
* Nominating new collaborators to this repository [#25481](https://github.com/joyent/node/issues/25481)
* Use something that’s not uberconference ?
### Standup:
* James: continued triaging of joyent/node issues, working on the LTS strawman proposal
* Bert: not much on node, some minor libuv and installer stuff
* Steven: Intl WG work
* Chris: Not too much on node, working on docs tooling
* Mikeal: working on a conferencing solution / replacement
* Trevor: webassembly discussion, api wg
* Brian: not much, triaging io.js issues and PRs
* Jeremiah: reviewing PRs and issues, more work on `_unrefActive()`
* Rod: busy week, worked on the build & release procedures. New jenkins job for all the types of release builds. v3.0.0 is now blocked on NAN. It’s a very big job. Node-gyp in `next` now works for rc’s and nightlies, and downloads a tarball of just the headers. First LTS WG meeting was also productive.
### Policy for PR blocking? [#2078](https://github.com/nodejs/io.js/issues/2078)
* Steven Belanger tagged this issue: can we come up with a policy for dealing with PRs that block each other?
* James clarified that this specific issue was about the url parsing changes, there were a couple of PRs that blocked each other
* Chris: the PRs here are a “hot stove” situation where they all break url functionality so they are not trivial
* Chris listed some of the blocking issues that are mainly held up because people are too busy so we probably need a way to communicate status to the community
* James: would like to table this issue until it really becomes a problem
* Bert: we could introduce some workflows - e.g. if you introduce an issue that is blocked on something else then you could mention that it’s blocked
* Jeremiah: more relevant to communicate when things are in the pipeline and provide feedback for timelines so people are reasonably blocked but can be unblocked if there is no activity
* Rod: doesn’t feel like something that needs a policy, perhaps it’s an open source 101 skill
* Mikeal: the problem is that often people who are blocking each other don’t have context so need shepherding by someone with context.
* Rod: doesn’t seem like there’s actionable items here, come back when there’s something more concrete to discuss
* Bert: the workers PR has stalled because of Petka’s lack of time, anything that it’s blocking should just move forward, url changes are unlikely to get in as they are now because they are so _breaking_
### Internationalization WG (Steven)
* https://github.com/nodejs/internationalization (repo)
* https://github.com/nodejs/internationalization/issues/4 (README)
* https://github.com/nodejs/internationalization/issues/5 (CFP)
* Steven introduced the work towards getting this set up
* Steven clarified the scope of the work (this is done in the README), it’s different to outreach and user assistance (i.e. the i18n translation stuff that io.js already has).
* Jeremiah suggested we name the group after `Intl` so it’s clearer what it’s about.
* James: It’s about Intl stuff in the code, unicode, REPL dying because of bad unicode
* Mikeal: We’ve talked about starting a formal translation/language group that unifies all of the independent translation efforts. That’s probably why people are showing up for this group thinking it’s the translation group that we’ve talked about setting up. We should set up that separate group and maybe use `Intl` as the name for this separate group.
* Bikeshedded naming for a little while.
* Conclusion: rename as the Intl WG or similar for clarity. (renamed to Intl)
### lts: strawman LTS cycle [lts#13](https://github.com/nodejs/LTS/pull/13) / Proposal: Release Process [#1997](https://github.com/nodejs/io.js/issues/1997)
* James walked through the LTS strawman proposal as formulated by the LTS WG
* Lots of bikeshedding about releases and LTS trivia
* Mikeal: we can probably move the release discussion to a formal proposal
### Next Meeting
July 8th 2015

131
doc/tsc-meetings/2015-07-08.md

@ -1,131 +0,0 @@
# Node Foundation TSC Meeting 2015-07-08
## Links
* **Audio Recording**: https://soundcloud.com/node-foundation/tsc-meeting-2015-07-08
* **GitHub Issue**: https://github.com/nodejs/node-convergence-archive/issues/64
* **Original Minutes Google Doc**: https://docs.google.com/document/d/1HuRtu5ZP7ZlrIp756EbZYo4I26v2RY-7CY1pr_3y1nY
## Agenda
Extracted from **tsc-agenda** labelled issues and pull requests prior to meeting.
### nodejs/io.js
* Default Unhandled Rejection Detection Behavior [#830](https://github.com/nodejs/io.js/issues/830)
### joyent/node
* Adding a "mentor-available" label [#25618](https://github.com/joyent/node/issues/25618)
## Minutes
### Present
* Mikeal Rogers
* Colin Ihrig (TSC)
* Ben Noordhuis (TSC)
* James Snell (TSC)
* Fedor Indutny (TSC)
* Bert Belder (TSC)
* Michael Dawson (TSC)
* Steven R Loomis (TSC)
* Alexis Campailla (TSC)
* Jeremiah Senkpiel (TSC)
* Julien Gilli (TSC)
* Chris Dickinson (TSC)
* Shigeki Ohtsu (TSC)
* Trevor Norris (TSC)
* Domenic Denicola
* Brian White (TSC)
* Rod Vagg (TSC)
### Review of the previous meeting
* Policy for PR blocking? [#2078](https://github.com/nodejs/io.js/issues/2078)
- Resolution was to deal with it on a case-by-case basis for now.
* Internationalization WG (Steven)
- Steven Loomis is going to kick off the working group.
- Steven: no further responses on the github issue.
- James: just need to get started
* lts: strawman LTS cycle [lts#13](https://github.com/nodejs/LTS/pull/13) / Proposal: Release Process [#1997](https://github.com/nodejs/io.js/issues/1997)
### Standup:
* Mikeal Rogers: wrote a new confrence call tool for us that uses Twillio
* Colin Ihrig: Not much, reviewing PRs, triaging issues.
* Ben Noordhuis: reviewed a lot of PRs, upgraded v8 in `next` and `next+1`.
* James Snell: Working on the LTS Proposal, triaging issues in joyent/node, investigating stuff for the upcoming openssl fix.
* Fedor Indutny: fixed node after v8 upgrade. Exposed critical issues.
* Bert Belder: Not much code, had conversations with Mike Dolan and James Snell about the foundation and organizational issues. Working through a laundry list of libuv PRs blocking the next release.
* Michael Dawson: Working on getting PowerPC to build on io.js, tested the security fix from last week, joyent/node triage.
* Steven R Loomis: Worked a bit on the Intl WG, not much else.
* Alexis Campailla: converged CI, almost done. Dealing with windows installer issues. Expect converged CI to work in a week.
* Jeremiah Senkpiel: General triaging and reviewing, helped do the release last friday. `_unrefActive` with optimizations with heap timers. At CascadiaJS the next of the week to get people’s feedback.
* Julien Gilli: Released 0.12.6 last week, working on setting up other people to do joyent/node releases, joyent/node issue triage
* Chris Dickinson: Working on docs more, have a new tool for docs to make sure the links are correct in a tree of docs, started a collaborator check-in on the io.js issue tracker, hopefully will be weekly.
Jeremiah: what is that doctool?
Chris: “count-docula”, a MDAST-based tool to verify correctness of the docs.
* Shigeki Ohtsu: Not much on io.js, preparing to update OpenSSL tonight to get the OpenSSL security fix out.
* Trevor Norris: Investigating the UTF8 decoder security issue and working on the fix. Reviewing PRs and being involved in the W3C Web Assembly working group.
* Domenic Denicola: Not much on io.js, travelling, stress testing the vm module.
* Brian White: Triaging issues, working on the javascript http parser more & benchmarking it.
* Rod Vagg: We should discuss the LTS proposal again since there was lots of work done on that. Working on lots, including the security fix from last friday (writing up a post-mortem for it), getting external people involved to review our security processes.
### Default Unhandled Rejection Detection Behavior [#830](https://github.com/nodejs/io.js/issues/830)
* Domenic: let’s say there was a magic way to detect when an error in an err-back style callback was not handled, what would we do? Print to stderr?
* Bert: We do have a history of printing things to stderr. We should follow browser semantics if we can, in favor of primnting a warning but nothing else.
* Discussion about the technicalities of handling unhandledRejections
* Rod: not sure we should do anything since detecting this is somewhat arbitrary.
* Domenic: there is a proposal for this that chrome implements behind a flag that comes close to how the unhandledRejection hook in node works
* Discussion about the technicalities of having a better hook for printing a warning after garbage collection of an unhandled rejection.
* See this thread for background detail of options in v8: https://code.google.com/p/v8/issues/detail?id=3093#c1
* Action: nothing now, maybe if v8 adds a hook for when rejections get garbage collected.
* Domenic: looking at v8, it seems to have most of the hooks, so this may be possible soon.
### Adding a "mentor-available" label [#25618](https://github.com/joyent/node/issues/25618)
* Folks are interested in contributing to larger tasks, need mentors to help them understand the process. Should we add a label?
* Julien: Many people are interested in making “deeper” contributions, but they need a mentor. Let people add a mentor-available tag so they can locate these.
* … part of the discussion missing here ...
* Resolution: let’s try it, one such label has already been added.
### Having more people managing releases for Node.js v0.10.x and v0.12.x
* Julien: I will have less time to do releases; it needs to become more of a team effort.
* Alexis: in the long term this will be a responsibility of the build team.
* Julien: unsure how responsibilities will be decided. LTS will need to sign off and build will need to produce the release.
* Jeremiah: the iojs/current releases are already a group effort. It’s just that the “long-term” v0.10/v0.12 releases fall on few individuals now.
* Julien: it’s a bit too much to handle for one person. Also people are sometimes unavailable or on vacation. Would like to have a group of about four people.
* Ben: more contributors recently signed up. I think Sam Roberts might be interested.
* Julien: would like to have a release management team.
* Chris: iojs has had the release manager propose other release managers. Open an issue for this.
* Resolved as such.
### lts: LTS Proposal https://github.com/nodejs/LTS#proposed-lts)/ Proposal: Release Process [#1997](https://github.com/nodejs/io.js/issues/1997)
* James: when are we cutting over to the converged stream? Thinking of late august, first LTS release in October. Is this a good time? Most users won’t start migrating until next year because of the holidays.
* Julien: what are other projects doing, when do they release?
* James: looking it into it, some do it in fall. No clear pattern.
* Alexis: what is the benefit of being on a fixed release schedule?
* James: benefit is it makes planning easier.
* Trevor: coming from the enterprise side, not having a predictable release schedule isn’t useful.
* Steven: ICU and Unicode has announced that there will be a yearly release. It’s been helpful for planning.
* James: It also ties into our regular release schedule and merging next into master etc. The next-to-master merge defines when we can do an LTS release. This should happen at least twice a year. The LTS is cut just before a merge (major bump), so by the time a LTS is cut it should have been stable for half a year.
* James: please kick tires on this proposal, get feedback from the user communities you’re connected to wrt the frequency and release date.
* Rod: the TSC should consider the timeframe, and the requirement that there should be two next-to-master merge yearly.
* Trevor: how does this fit with a 6-week release schedule on master?
* James: depends on the schedule.
* Domenic: I don’t see the problem. Just take a 6 months old release and turn it into an LTS.
* Rod/James/Trevor: because version numbers. The LTS version number needs to be a continuation of a release version.
* Rod: fixed date, or part of the month.
* Chris, Rod: get feedback, comment on the issue
### Next Meeting
July 15th 2015

94
doc/tsc-meetings/2015-07-15.md

@ -1,94 +0,0 @@
# Node Foundation TSC Meeting 2015-07-15
## Links
* **Audio Recording**: https://soundcloud.com/node-foundation/tsc-meeting-2015-07-15
* **GitHub Issue**: https://github.com/nodejs/node-convergence-archive/issues/67
* **Original Minutes Google Doc**: https://docs.google.com/document/d/1r8boI4E67Cq7PEsYeIpXkFZM0be4Ww5UDlNr_uXOop0
## Agenda
Extracted from **tsc-agenda** labelled issues and pull requests prior to meeting.
### nodejs/io.js
* Intl [#238](https://github.com/nodejs/io.js/issues/238)
* TC39 representation [#2153](https://github.com/nodejs/io.js/issues/2153)
### Other
* Foundation Discussion
* lts: [LTS Proposal](https://github.com/nodejs/LTS#proposed-lts) / Proposal: Release Process [#1997](https://github.com/nodejs/io.js/issues/1997)
## Minutes
### Present
* Mikeal Rogers
* Colin Ihrig (TSC)
* James Snell (TSC)
* Fedor Indutny (TSC)
* Michael Dawson (TSC)
* Steven R Loomis (TSC)
* Alexis Campailla (TSC)
* Jeremiah Senkpiel (TSC)
* Shigeki Ohtsu (TSC)
* Trevor Norris (TSC)
* Domenic Denicola
* Brian White (TSC)
* Angela Brown (Linux F)
* Mike Dolan (Linux F)
* Laura Kempke (Linux F)
* Bert Belder (TSC)
### Review of the previous meeting
* Default Unhandled Rejection Detection Behavior [#830](https://github.com/nodejs/io.js/issues/830)
* Adding a "mentor-available" label [#25618](https://github.com/joyent/node/issues/25618)
* Having more people managing releases for Node.js v0.10.x and v0.12.x
* lts: [LTS Proposal](https://github.com/nodejs/LTS#proposed-lts) / Proposal: Release Process [#1997](https://github.com/nodejs/io.js/issues/1997)
### Standup:
* Steven Loomis: Intl WG - https://github.com/nodejs/io.js/issues/2165
* Mikeal Rogers: Meeting with the Linux Foundation
* Colin Ihrig: Issues & PRs, met with Julien & Sam for joyent/node release onboarding
* James Snell: Deep diving on a couple issues, looking into TC39 involvement, LTS feedback
* Fedor Indutny: some bugs and node-spdy, not too much
* Alexis Campailla: build-related things to converge the CI, most of the work is done, trying to get the CI working for 0.10. Also speeding up arm builds. +Windows issues.
* Jeremiah Senkpiel: CascadiaJS Feedback was positive for the project convergence, sick from the cascadiajs cold, not much else.
* Shigeki Ohtsu: Did the security update for OpenSSL on thursday
* Domenic Denicola: Not much, working on the unhandled rejection spec.
* Brian White: Mostly working on the JS Http parser, also working on a JSPerf.com-like tool for testing different node versions from the browser.
### Foundation Discussion (@mikeal leading)
Security policy best-practices
### Intl [#238](https://github.com/nodejs/io.js/issues/238)
Discussion if we can land this into `master` rather than `next`.
Action: Check that there is no objection to landing in `master`.
Steven, Domenic, James: Should be a direct port from 0.12, we can work on making a PR.
### TC39 representation [#2153](https://github.com/nodejs/io.js/issues/2153)
Discussion about the legalities of joining officially and if unofficial representation would be workable.
Action: Domenic will invite Mikeal to check out one of the TC39 meetings.
### lts: [LTS Proposal](https://github.com/nodejs/LTS#proposed-lts) / Proposal: Release Process [#1997](https://github.com/nodejs/io.js/issues/1997)
Mikeal: We are effectively working under the new release proposal ([#1997](https://github.com/nodejs/io.js/issues/1997)) now with how `next` / 3.0.0 is going.
Jeremiah: Only real contested point is how we might version the `next` branch releases.
Domenic: Having multiple release train versionings in confusing.
Action: Mikeal will update the current PR and separate any contention points into new PRs for discussion.
### Next Meeting
July 22nd 2015

168
doc/tsc-meetings/2015-07-22.md

@ -1,168 +0,0 @@
# Node.js Foundation TSC Meeting 2015-07-22
## Links
* **Audio Recording**: https://soundcloud.com/node-foundation/tsc-meeting-2015-07-22
* **GitHub Issue**: https://github.com/nodejs/node-convergence-archive/issues/69
* **Original Minutes Google Doc**: https://docs.google.com/document/d/1r8boI4E67Cq7PEsYeIpXkFZM0be4Ww5UDlNr_uXOop0
## Agenda
Extracted from **tsc-agenda** labelled issues and pull requests prior to meeting.
### nodejs/io.js
* doc: add GPG fingerprint for cjihrig [#2217](https://github.com/nodejs/io.js/pull/2217)
* Process & Approval for Collab Summit Travel Fund [#2213](https://github.com/nodejs/io.js/issues/2213)
* TC39 representation for the Node.js Foundation [#2153](https://github.com/nodejs/io.js/issues/2153)
* Next branch release versioning [#2215](https://github.com/nodejs/io.js/issues/2215)
## Minutes
### Present
* Mikeal Rogers
* Rod Vagg (TSC)
* Colin Ihrig (TSC)
* James Snell (TSC)
* Fedor Indutny (TSC)
* Michael Dawson (TSC)
* Steven R Loomis (TSC)
* Jeremiah Senkpiel (TSC)
* Brian White (TSC)
* Ben Noordhuis (TSC)
* Trevor Norris (TSC)
* Chris Dickinson (TSC)
* Mike Dolan (Linux F)
* Emily Ratliff (Linux F)
### Security Policy Discussion
Emily Ratliff from the LF has joined us to help with our security and disclosure policy. TSC members were sent a briefing prior to the meeting.
Discussed ISO 29147 “Vulnerability Disclosure Overview” and ISO 30111 “Vulnerability Handling Processes Overview”.
### Review of the previous meeting
* Foundation Discussion (@mikeal leading)
* Intl [#238](https://github.com/nodejs/io.js/issues/238)
* TC39 representation [#2153](https://github.com/nodejs/io.js/issues/2153)
* lts: LTS Proposal (https://github.com/nodejs/LTS#proposed-lts)[ Proposal: Release Process] [#1997](https://github.com/nodejs/io.js/issues/1997)
### Standup:
* Mikeal Rogers: preparing for the foundation board meeting
* Rod Vagg: working on 3.0 and release candidates / NAN
* Colin Ihrig: reviewing issues & PRs, worked with julien to do releases from joyent/node 0.x branches
* James Snell: working on smoke-testing npm modules
* Fedor Indutny: doing so bug fixes, and reviewing PRs
* Michael Dawson: some joyent/node issue triage, PPC build work
* Steven R Loomis: some Intl WG work, working on getting the Intl commits from joyent/node into io.js
* Jeremiah Senkpiel: reviewing issues + prs, doing work on REPL in light of 3.0; fixing bugs in REPL
* Brian White: working more on the in-browser node.js/io.js benchmarking tool, which is now in a usable state. using it now to test current and future performance improvement techniques for the the js http parser
* Ben Noordhuis: (no mic)
* Trevor Norris: did a fix for the buffer implementation for the 3.0 release
* Chris Dickinson: npm work.
### doc: add GPG fingerprint for cjihrig [#2217](https://github.com/nodejs/io.js/pull/2217)
* Rod +1
* James +1
* Fedor +1
* Michael +1
* Steven +1
* Jeremiah +1
* Brian +1
* Ben +1
* Trevor +1
* Chris +1
Action: make sure Colin’s GPG key setup is correct on the PR, after we can merge and Rod can add Colin’s credentials to the build server.
### Process & Approval for Collab Summit Travel Fund [#2213](https://github.com/nodejs/io.js/issues/2213)
* Mikeal: budget auditing requires that spending be approved by the board - need to approve the budget and the process for expenditure of those funds. Mikeal has a proposal for the process with basic limits and a process for having the TSC approve expenditure beyond that.
**Process as outlined**
* TSC approves target budget (max amount to spend on travel) and caps on each type of spend (with the possibility that the TSC can approve a specific spend over if need be).
* Contributors in need of the fund apply (this will happen in the GitHub thread) but should explicitly state if they need flight, accommodation or both.
* If the number of contributors in need of the fund exceeds the target budget the TSC will prioritize the list of contributors applying for the fund.
Voting on approving the process stated above:
* Rod: +1
* James: +1
* Fedor: +1
* Michael: +1
* Steven: +1
* Jeremiah: +1
* Brian: +1
* Ben: +1
* Trevor: +1
* Chris: +1
Specific proposal for August
* 15K max budget (we had previously talked about 10K but I don't think that is enough)
* Approve a $900 max spend per person on accommodations.
* Approve a $500 max spend on domestic travel
* Approve a $1500 max spend on international travel (if someone has to go over it just requires additional TSC approval)
* Rod: +1
* James: +1
* Fedor: +1
* Michael: +1
* Steven: +1
* Jeremiah: +1
* Brian: +1
* Ben: +1
* Trevor: +1
* Chris: +1
Approval for extra expenditure for @joaocgreis (from Portugal): $1,742.66
* Rod: +1
* James: +1
* Fedor: +1
* Michael: +1
* Steven: +1
* Jeremiah: +1
* Brian: +1
* Ben: +1
* Trevor: +1
* Chris: +1
Approval for expenditure on @yosuke-furukawa (from Japan) max spend of $2400
* Rod: +1
* James: +1
* Fedor: +1
* Michael: +1
* Steven: +1
* Jeremiah: +1
* Brian: +1
* Ben: +1
* Trevor: +1
* Chris: +1
### Next branch release versioning [#2215](https://github.com/nodejs/io.js/issues/2215)
* Rod outlined the state of play:
- LTS WG moved from “proposal” to “plan” but are still depending on the stable release branch having a clear process
- LTS WG discussed a proposal by Trevor for how to handle next/canary/alpha & master & release branches & LTS branches: https://gist.github.com/trevnorris/7620a64b086e95271197
* Mikeal: it’s more helpful if we think about V8 upgrades as a pull-request to master rather than a separate “next” that has to be separately managed.
Much bikeshedding was had in an attempt to move forward.
Group agreed in general with Trevor’s proposal, will organise further discussions amongst the group of interested parties at another time.
### Next Meeting
July 29th 2015

89
doc/tsc-meetings/2015-07-29.md

@ -1,89 +0,0 @@
# Node.js Foundation TSC Meeting 2015-07-29
## Links
* **Audio Recording**: https://soundcloud.com/node-foundation/tsc-meeting-2015-07-29
* **GitHub Issue**: https://github.com/nodejs/node-convergence-archive/issues/71
* **Original Minutes Google Doc**: https://docs.google.com/document/d/1FBmDczHD4D8jfffc6A8CW-K9mmT0KI8shG6dm_d3jXI
* Previous minutes: https://docs.google.com/document/d/1eCETYn44gAOUp0udl22QxqyxrJ0oEeAFRdWHDCIq9V4
## Agenda
Extracted from **tsc-agenda** labelled issues and pull requests prior to meeting.
### nodejs/io.js
* Next branch release versioning [#2215](https://github.com/nodejs/io.js/issues/2215)
* TSC Chair - Election? [#2136](https://github.com/nodejs/io.js/issues/2136)
## Minutes
### Present
* Mikeal Rogers
* Rod Vagg (TSC)
* Colin Ihrig (TSC)
* James Snell (TSC)
* Fedor Indutny (TSC)
* Michael Dawson (TSC)
* Steven R Loomis (TSC)
* Jeremiah Senkpiel (TSC)
* Shigeki Ohtsu(TSC)
* Ben Noordhuis (TSC)
* Trevor Norris (TSC)
* Chris Dickinson (TSC)
* Alexis Campailla (TSC)
* Bert Belder (TSC)
### Review of the previous meeting
* Security Policy Discussion
* doc: add GPG fingerprint for cjihrig [#2217](https://github.com/nodejs/io.js/pull/2217)
* Process & Approval for Collab Summit Travel Fund [#2213](https://github.com/nodejs/io.js/issues/2213)
* Next branch release versioning [#2215](https://github.com/nodejs/io.js/issues/2215)
### Standup:
* Mikeal Rogers: Got ready for the board meeting, working to get the new website spun up based on the iojs.org build system
* Rod Vagg: Finished writing NAN 2.0 documentation
* Colin Ihrig: Issues & PRs, did the 2.5.0 release (armv6 build had an issue), playing around with the citgm package smoke-testing tool
* James Snell: Working on citgm (npm package smoke-testing), halfway done writing up the release plan
* Fedor Indutny: ?
* Michael Dawson: Triaging joyent/node issues / PRs, looking at AIX build support on the `next` branch, looking at updating some docs
* Steven R Loomis: Worked on the Intl converge PR [#2264](https://github.com/nodejs/io.js/pull/2264)
* Jeremiah Senkpiel: Issue and PR review, helping to get someone to start contributing to core
* Ben Noordhuis: not much, reviewed some PRs this week and did some minor patches
* Trevor Norris: Just had time to review some issues and respond to PRs
* Chris Dickinson: Not much, did docs work, trying to document streams (again), and the REPL history-paintext change PR [#2224](https://github.com/nodejs/io.js/pull/2224)
* Alexis Campailla: Working on CI/Jenkins convergence, and some windows issue triage
* Shigeki Ohtsu: Working on the updated crypto module for weak ciphers
* Bert Belder: Not much except started reviewing a VS2015 support PR
#### Next branch release versioning [#2215](https://github.com/nodejs/io.js/issues/2215)
Discussion about the release plan (not yet written up, James Snell is working on that.)
#### TSC Chair - Election? [#2136](https://github.com/nodejs/io.js/issues/2136)
Vote?
* Colin: +1
* Chris: +1
* James: +1
* Fedor: +1
* Michael: +1
* Steven: +1
* Jeremiah: +1
* Shigeki: +1
* Ben: +1
* Trevor: +1
* Chris: +1
* Alexis: +1
* Bert: +1
### Next Meeting
Not happening on August 5th (as it usually would).
Possibly a (short) TSC meeting will be held during the summit.

87
doc/tsc-meetings/2015-08-12.md

@ -1,87 +0,0 @@
# Node.js Foundation TSC Meeting 2015-08-12
## Links
* **Audio Recording**: https://soundcloud.com/node-foundation/tsc-meeting-2015-08-12
* **GitHub Issue**: https://github.com/nodejs/node-convergence-archive/issues/71
* **Minutes Google Doc**: https://docs.google.com/document/d/1q2bFjnf0Y23Ljxoze56Pmrbailaj5-UAqIUqIYVhiIk
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/1FBmDczHD4D8jfffc6A8CW-K9mmT0KI8shG6dm_d3jXI>_
## Agenda
Extracted from **tsc-agenda** labelled issues and pull requests prior to meeting.
* Travel assistance amendment (no issue for this)
* FYI: Collaboration WG: https://github.com/nodejs/collaboration
* Summit recap
* level-set on repo rename
* Future: “project lifecycle” (Mikeal) - process by which top level projects are added (libuv, node-gyp, etc), (conferences…)
## Minutes
### Present
* Mikeal Rogers
* Rod Vagg (TSC)
* James Snell (TSC)
* Michael Dawson (TSC)
* Steven R Loomis (TSC)
* Chris Dickinson (TSC)
* Alexis Campailla (TSC)
* Brian White (TSC)
### Review of the previous meeting
* Next branch release versioning [#2215](https://github.com/nodejs/io.js/issues/2215)
* TSC Chair - Election?
### Standup:
* Mikeal: summit, code & learn project for new collab
* Rod: Summit, migrating nodejs/io.js to nodejs/node
* James: convergence, joyent/node PRs
* Michael: patch for AIX, 0.12 work, Benchmarking meeting
* Steven: Summit, 1st Intl meeting, Intl convergence work, VS2015 fixes
* Chris: Summit, Docs repo has taken off, [HTTP lifecycle doc by Bryan English](https://github.com/nodejs/docs/blob/master/src/guides/anatomy-of-an-http-transaction.md)
* Alexis: Summit, progress on CI convergence, reviewed some PRs.
* Brian: Triaging and reviewing PRs and Issues.
### Travel assistance amendment (no issue for this)
* Chris Dickinson adding $500 to the travel expenditure
* Passed unanimously.
### FYI: Collaboration WG: https://github.com/nodejs/collaboration
* Steven: new WG coming out of the Summit, Sean (@snostorm) is taking lead on this. One idea under discussion now is to have a multi-timezone meetings for the language working groups.
* Mikeal: is this going to serve as a collaboration point for the language groups?
* Steven: https://github.com/nodejs/Intl/issues/9
* Rod: beyond the language groups, what are the aims of this new group?
* Steven: trying to address, or having a place to discuss, common items across working groups.
* James: filling a need to liaise with the other working groups, acting as an intermediary
### Summit recap
* Mikeal: 6 sessions in 2 days, not solid answers to problems but a shared understanding of the common problems, feels like we are on the same page from that
* Mikeal: bigger sessions: what is the Node API and what is the Node platform? V8 release cycle. Errors and the inconsistencies. Kept coming back to the collaboration WG, which is why it exists. Talked about expanding the collaborator base, idea was to do some collaboration sprints to bring new folks up to speed, https://github.com/nodejs/code-and-learn comes from that idea (there is foundation budget for that).
* Mikeal: there were extensive notes taken, those are being edited now and will be published into the repo(s) and turned into blog posts.
### level-set on repo rename
* James: what are the remaining things to do - there’s confusion around the naming
- Renaming everything in the documentation (README, docs & other misc docs)
- Renaming binary
- Alexis: finishing convergence work
* Mikeal: preparing a blog post about what’s happening, will be reviewed and posted soon
### Future: “project lifecycle” (Mikeal) - process by which top level projects are added (libuv, node-gyp, etc), (conferences…)
* Mikeal: the TSC charter states that we will adopt a project lifecycle that will allow us to bring in other _top level projects_. Additionally, the TSC has had to take on board some non-technical work because of its position in the Foundation (voting on expenditure, etc.), a number of TSC members don’t want to be involved in that kind of activity. Have started drafting a new project lifecycle plan which splits off a “Core TSC” that contains the existing TSC members but with a focus on Node.js Core work while the existing TSC will take on board the higher-level foundation work and members can optionally resign if they aren’t interested in that work and we can expand it to non-Core collaborators. https://github.com/nodejs/TSC/tree/lifecycle
### Next Meeting
August 19th

120
doc/tsc-meetings/2015-08-19.md

@ -1,120 +0,0 @@
# Node.js Foundation TSC Meeting 2015-08-19
## Links
* **Audio Recording**: https://soundcloud.com/node-foundation/tsc-meeting-2015-08-19
* **GitHub Issue**: https://github.com/nodejs/node/issues/2435
* **Minutes Google Doc**: https://docs.google.com/document/d/1xsj_4UlrLNxahRvC7SpLtFM3D-Ks6CZEqEM5nyj6bjk
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/1q2bFjnf0Y23Ljxoze56Pmrbailaj5-UAqIUqIYVhiIk>_
## Agenda
Extracted from **tsc-agenda** labelled issues and pull requests prior to meeting.
* Procedure for rolling out node-accept-pull-request [#2434](https://github.com/nodejs/node/issues/2434)
* Release procedure changes & nominating @sam-github and @jasnell as releasers [#2416](https://github.com/nodejs/node/issues/2416)
## Minutes
### Present
* Mikeal Rogers
* Rod Vagg (TSC)
* James Snell (TSC)
* Michael Dawson (TSC)
* Steven R Loomis (TSC)
* Chris Dickinson (TSC)
* Alexis Campailla (TSC)
* Brian White (TSC)
* Jeremiah Senkpiel (TSC)
* Shigeki Ohtsu (TSC)
* Trevor Norris (TSC)
* Domenic Denicola
* Ben Noordhuis (TSC)
* Colin Ihrig (TSC)
* Bert Belder (TSC)
### Standup
* Mikeal Rogers: Linuxconf, preparing next board meeting agenda, nailing down the foundation conf
* Rod Vagg: build work, memory leak testing, progress towards v4 (mainly infra)
* James Snell: some joyent/node PR triaging, preparing for nodeconf.eu
* Michael Dawson: nodeconf.eu, some AIX build work, talking to the v8 team about security notifications
* Steven R Loomis: Intl WG, landed Intl with small-icu by default in nodejs/node
* Chris Dickinson: first docs WG meeting, working on streams docs (again), working on docs tooling
* Alexis Campailla: working on ci convergence and jenkins jobs
* Brian White: not much, looking over issues and PRs, submitted a couple PRs
* Jeremiah Senkpiel: not so much, working on 0.10, 0.12 -> v4 upgrade docs, 3.1.0 release which should be ready straight after this meeting.
* Shigeki Ohtsu: little time to work on node right now, joined the LTS meeting to discuss OpenSSL LTS
* Trevor Norris: reviewing issues and PRs, noticed a bug in asyncwrap
* Domenic Denicola: issues and PRs, v8 team has a new Project Manager who is more interested in node; communicated our API stability concerns to him
* Ben Noordhuis: fixed a big memory leak, fixed a regression in windows module loading, reviewing PRs, responding to bug reports
### Review of the previous meeting
* Travel assistance amendment (no issue for this)
* FYI: Collaboration WG: https://github.com/nodejs/collaboration
* Summit recap
* level-set on repo rename
* Future: “project lifecycle” (Mikeal) - process by which top level projects are added (libuv, node-gyp, etc), (conferences…)
### Procedure for rolling out node-accept-pull-request [#2434](https://github.com/nodejs/node/issues/2434)
* Discussed some potential concerns, which were alleviated:
* Jeremiah: Wondered how to land PRs where nits needed to be fixed.
* Bert: Concerns about Jenkins costantly building the wrong PR in the io.js CI infrastructure.
* Trevor: asked for a dropdown to pick the reviewers.
* Bert: asked whether the job would support landing multiple commits. Alexis confirmed this.
* Alexis: mentioned that there is also an node-accept-commit job that is more low-level and advanced.
### Release procedure changes & nominating @sam-github and @jasnell as releasers [#2416](https://github.com/nodejs/node/issues/2416)
Votes for @jasnell:
* Rod Vagg: +1
* Michael Dawson: +1
* Steven R Loomis: +1
* Chris Dickinson: +1
* Alexis Campailla: +1
* Brian White: +1
* Jeremiah Senkpiel: +1
* Shigeki Ohtsu: +1
* Trevor Norris: +1
* Ben Noordhuis: +1
* Colin Ihrig: +1
* Bert Belder: +1
Votes for @sam-github:
* Rod Vagg: +1
* Michael Dawson: +1
* Steven R Loomis: +1
* Chris Dickinson: +1
* Alexis Campailla: +1
* Brian White: +1
* Jeremiah Senkpiel: +1
* Shigeki Ohtsu: +1
* Trevor Norris: +1
* Ben Noordhuis: +1
* Colin Ihrig: +1
* Bert Belder: +1
No objections to combining the a whole "release team" to handle all release branches including 0.10, 0.12, stable and LTS.
### node-gyp is now in our org [#2379](https://github.com/nodejs/node/issues/2379)
* Rod: node-gyp has a busy issue tracker and has no tests, needs more eyes
* Ben: Zero tests?
* Rod: Correct.
* Domenic: on Windows Chromium’s depot_tools will automatically download VS community edition and put it in the right place. Someone with copious free time could have node-gyp do similar things.
* Discussed maybe looking at `gn` (the eventual replacement for `gyp`)
* Domenic: even v8 still uses gyp, don’t worry about it for a good while until noise about it being deprecated gets louder
* Rod: issue [#151](https://github.com/nodejs/build/issues/151) in build has a discussion about precompiled native addons. Chime in!
## Next Meeting
August 26th

112
doc/tsc-meetings/2015-08-26.md

@ -1,112 +0,0 @@
# Node Foundation TSC Meeting 2015-08-26
## Links
* **Audio Recording**: https://soundcloud.com/node-foundation/tsc-meeting-2015-08-26
* **GitHub Issue**: https://github.com/nodejs/node/issues/2560
* **Minutes Google Doc**: https://docs.google.com/document/d/1aB76ClCgdjZUw3p-gHq9j6YwU11zWgJ4pmYPEWk6gjE
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/1q2bFjnf0Y23Ljxoze56Pmrbailaj5-UAqIUqIYVhiIk>_
## Agenda
Extracted from **tsc-agenda** labelled issues and pull requests in the nodejs org prior to meeting.
### joyent/node
* Update README to reflect move to nodejs/node [#25897](https://github.com/joyent/node/pull/25897)
### nodejs/node
* doc: merge CHANGELOG.md with joyent/node ChangeLog [#2536](https://github.com/nodejs/node/pull/2536)
* (guidance on) rename of "language groups" from iojs-\* to nodejs-\*? [#2525](https://github.com/nodejs/node/issues/2525)
* Node.js v4 Release Timeline [#2522](https://github.com/nodejs/node/issues/2522)
### nodejs/collaboration
* How to onboard into WG? [#4](https://github.com/nodejs/collaboration/issues/4)
## Minutes
### Present
* Rod Vagg (TSC)
* Brian White (TSC)
* Steven R Loomis (TSC)
* Fedor Indutny (TSC)
* Bert Belder (TSC)
* Colin Ihrig (TSC)
* Ben Noordhuis (TSC)
* Mikeal Rogers
* Alexis Campailla (TSC)
* Trevor Norris (TSC)
* Shigeki Ohtsu (TSC)
### Review of the previous meeting
* Travel assistance amendment (no issue for this)
* FYI: Collaboration WG: https://github.com/nodejs/collaboration
* Summit recap
* level-set on repo rename
* Future: “project lifecycle” (Mikeal) - process by which top level projects are added (libuv, node-gyp, etc), (conferences…)
### Standup:
* Rod Vagg: v4 release stuff, got certificates from/for the foundation, new website including CDN offering from CloudFlare
* Brian White: continuing work on benchmark app for node.js/io.js, triaging, reviewing/answering issues and pull requests.
* Steven R Loomis: Intl for convergence VS2015
* Fedor Indutny: http perf improvement PR, reviewing PRS, looking at issue for shared ports for http cluster
* Bert Belder: busy with work, reviewing libuv PRs and responding to issues
* Colin Ihrig: Rename from io.js to Node.js, reviewing issues and PRs
* Ben Noordhuis: Running native addons as part of CI, libuv bugs, reviewing PRs
* Mikeal Rogers: Website ready for release, working on CloudFlare CDN stuff
* Alexis Campailla: CI for release, parallelising test runs for ARM, looking at managing dependencies with git
* Trevor Norris: reviewing PRs and issues
* Shigeki Ohtsu: reviewing convergence tests for SSLv2/3, working on TLS ALPN features before freeze
### Update README to reflect move to nodejs/node [#25897](https://github.com/joyent/node/pull/25897)
* Alexis: made changes in CI to prepare for this, we’ll keep PRs in original repo, node-accept-pull-request will land changes in new repo as well, mirroring changes in 0.10 and 0.12 across both old and new repos. Still using the old Jenkins for releases for 0.10 and 0.12 right now and that doesn’t depend on repo name & location.
Target ETA for transition: Monday.
### doc: merge CHANGELOG.md with joyent/node ChangeLog [#2536](https://github.com/nodejs/node/pull/2536)
* Rod seeking confirmation from this group that this was _not a bad idea_.
* Discussion about documentation for people upgrading from older versions of Node and having a linear history. Jeremiah has been working on 0.10 -> v4 documentation.
### (guidance on) rename of "language groups" from iojs-\* to nodejs-\*? [#2525](https://github.com/nodejs/node/issues/2525)
* Steven discussed renaming the language groups
* Mikeal: some groups are not in a position to make decisions because they are not active but the ones that are should be given the opportunity to agree or disagree to the move rather than us imposing a move on them. We should post an issue in their repos.
* Steven: we should give them a timeline in issues in their repos
* Discussed naming, could be “lang” or “community” to make it more clear what they are about.
* ACTION: Steven to add a proposal to #2525, let TSC/collaborators add comments, later in the week will reach out to each of the groups.
### Node.js v4 Release Timeline [#2522](https://github.com/nodejs/node/issues/2522)
* Rod gave a summary of the proposed release timeline https://github.com/nodejs/node/issues/2522 (and appologised for documenting it as “the” release proposal just for the sake of getting it done).
- “feature freeze” Friday, 28th of August, cut v4.x branch
- nodejs.org DNS changeover to new website Monday, 31st of August
- release Thursday, 3rd of September
- RC builds between website and release
- backup release date of Monday, 7th of September if absolutely necessary to punt
* Discussed the outstanding items in the 4.0.0 milestone: https://github.com/nodejs/node/milestones/4.0.0, some concerning items:
- mdb support is late and may not get done, might have to be a semver-minor prior to LTS
- vcbuilt.bat needs to use the new build_release target and we have to verify that all builds have Intl enabled - Steven to work with Rod on this
- `process.send()` async/sync, Ben said that this is async on all platforms now (was just Windows previously but now it’s cross-platform) but it’s missing a callback so there’s no way of doing back-pressure. No time to add this prior to v4 but could be done as semiver-minor later. Ben agreed to document current behaviour properly in the docs.
- `_unrefActive` is in Jeremiah’s hands, he will land the 0.12 changes as the io.js version is terrible. Discussed further perf improvements but agreed to leave those changes till later, ideally till v5 because of the potential for subtle edge-case bugs being introduced.
### How to onboard into WG? [nodejs/collaboration#4](https://github.com/nodejs/collaboration/issues/4)
* Discussed GitHub onboarding mechanics
### V8 embedders unified debugger proposal
* Trevor raised https://github.com/nodejs/node/issues/2546 which is a proposal for a unified debugger for V8 embedders using Chromium DevTools.
* Discussion ensued, agreed to leave it for GitHub discussion unless/until there is something the TSC actually needs to make a decision about.
### Next Meeting
September 2nd

418
doc/tsc-meetings/2015-09-02.md

@ -1,418 +0,0 @@
# Node Foundation TSC Meeting 2015-09-02
## Links
* **Audio Recording**: https://soundcloud.com/node-foundation/tsc-meeting-2015-09-02
* **GitHub Issue**: https://github.com/nodejs/node/issues/2654
* **Minutes Google Doc**: https://docs.google.com/document/d/1rXBdtsD9PJTExNXgzNZ9bez9oOjW45kLPjun4zdt0dY
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/1aB76ClCgdjZUw3p-gHq9j6YwU11zWgJ4pmYPEWk6gjE>_
## Agenda
Extracted from **tsc-agenda** labelled issues and pull requests in the nodejs org prior to meeting.
### nodejs/node
* deps: update v8 to 4.5.103.30 [#2632](https://github.com/nodejs/node/pull/2632)
* Inspecting Node.js with Chrome DevTools [#2546](https://github.com/nodejs/node/issues/2546)
* Node.js v4 Release Timeline [#2522](https://github.com/nodejs/node/issues/2522)
* doc: update COLLABORATOR_GUIDE.md [#2638](https://github.com/nodejs/node/pull/2638)
### nodejs/build
* Merge job overwrites metadata [#179](https://github.com/nodejs/build/issues/179)
## Minutes
### Present
* Rod Vagg (TSC)
* Brian White (TSC)
* Steven R Loomis (TSC)
* Fedor Indutny (TSC)
* Bert Belder (TSC)
* Colin Ihrig (TSC)
* Trevor Norris (TSC)
* James M Snell (TSC)
* Chris Dickinson (TSC)
* Jeremiah Senkpiel (TSC)
### Standup
* Rod Vagg (TSC): node v4 prep, new website
* Brian White (TSC): issue/PR reviewing, working on JS DNS implementation some more
* Steven R Loomis (TSC): syncing with james, creating text for renaming of language groups (#2525), intl triaging, commenting on joyent/node issues
* Bert Belder (TSC): indisposed until end of october
* Colin Ihrig (TSC): reviewing issues/prs
* Trevor Norris (TSC): prs/issues, finagling the new build pr landing tool
* James M Snell (TSC): old prs in joyent/node cleaned up (64 remaining, wow), citgm tool updates, child process arguments pr, nodeconf.eu
* Michael Dawson (TSC): AIX support PR, some triage with Devin, preparing for NodeConfEU
* Chris Dickinson (TSC): Static analysis work (ongoing), docs (slowly), npm
* Jeremiah Senkpiel (TSC): v4 release prep
* Fedor Indutny (TSC): v8 arraybuffer perf, patch landed on v8; reviewing PRs
### Jenkins merge jobs always overwrites PR-URL and Reviewed-By [#179](https://github.com/nodejs/build/issues/179)
Trevor: currently if you submit a job to land a pr, it will always remove all existing metadata and re-apply it based on the info passed to the jenkins build. from convo, good fix is to let old metadata persist & only append new metadata if it’s entered, if no metadata entered, nothing appended
Issue with current state: current system does not work for cherry-picks onto release branch — will wipe metadata and replace it
Goal: solidify with TSC that this is a good path forward
James: absolutely, +1
Jeremiah: clarification on which branches this applies to
Rod: cherry-picks are becoming increasingly difficult on iojs anyway, so the pr landing job may be master-specific
James: no mixing of “with pr tool” and “manually”, things go bad quickly that way
Trevor: cherry-pick PRs are accumulating too many cherry-picks; runnin it through the system manually doesn’t add useful info
Domenic: description of chromium
- tests are run after landing
- no one is allowed to land commits if the build is broken on a branch
- sheriff of the day is responsible for fixing the issue
- in practice it’s painful, but it’s important for keeping things sane
Trevor: this would make us better about flaky tests, also, admiration for how sporadically our flaky tests break
Jeremiah: trying to do this now before v4 seems like a bad idea
Rod: we’re smoothing out a little bit; circle back to original topic, we’re kind of talking about the larger issue, let the trial of the tool continue and come back to the discussion later. specifically: ask that metadata not be overridden in a github issue
Domenic: addressing jeremiah’s concern: should we not run the trial while releasing v4?
Trevor: agreement — have felt pain from this as we march to v4
Jeremiah: stuff that gets released to people is in the release branches, if we’re not using the pr tool on that branch, what is the point of using this tool?
Rod: this will become more of a problem as we have more extended and LTS
Domenic: clarification: intent of ci is to make sure tests pass everywhere
Trevor: this tool only runs a subset
Rod: since we branched 3.x there’s 4 commits in the tree that have faulty/missing metadata — like that the pr tool is enforcing this metadata, maybe move to using github status api for telling us whether the metadata is OK
Trevor: clarify: contributors have landed commits that lack metadata?
Rod: yep
Trevor: argh
Jeremiah: github suggested we use the status api
Trevor: status api autoruns?
Rod: you hook it up to webhooks, has in-progress and pass/fail
Trevor: TJ can verify that devs destroy jenkins (multiple force pushes explode the jenkins box with so many jobs)
Rod: we can cancel on force push (or add a “trevor is pushing, wait half an hour to run the tests” exception, har har)
Jeremiah: you can tell if it’s been run on the last commits
Rod: multiple statuses — up to 100? — “this pr is passing on these platforms! this pr has the right metadata. this pr lints well.”
Rod: let’s move on!
James: what’s the action item?
Rod: don’t feel that we should cancel the trial
Trevor: two prs that prevent segfaults because of other flaky tests that have to be reapplied
James: in the 4.x branch do we need to use test-pr job to land commits?
Rod: nope, cherry-pick onto those branches, only use the tool on master
Jeremiah: it’s weird to use it on the unstable branch. I guess we could make it better for release branches in the meantime
* ci-run middle of hte night us time this has a
Rod: vote for who whether we’d like to put this on hold
Jeremiah: +0 put on hold
Rod: who would like to continue it?
...crickets...
Trevor: give me another day
James: one PR took 8 hours to land last friday
Jeremiah: they take about an hour to land right now
Rod: they are getting quicker, adding raspberrypis to the cluster. good incentive to make node startup time quicker! arm startup times have gone down over the last month or so
Rod: let’s move on
### doc: update COLLABORATOR_GUIDE [#2638](https://github.com/nodejs/node/pull/2638)
Jeremiah: Alexis wanted to put the pr tool into the collaborator guide should punt on this right now notifying collaborators on issues is more effective messaging than the docs
Rod: let’s hold off
### deps: update v8 to 4.5.103.30 [#2632](https://github.com/nodejs/node/pull/2632)
Rod: looking at the possibility of jumping to 4.5 for the v4 release it’s ready to merge. ofrobots has been doing the work, it’s good to go, there are pros and cons whether we stick with 4.4 or 4.5 for this release & associated LTS has anyone done any work on testing NAN?
Bert: what breaks? what are the cons?
Domenic: looking at v8 by code inspection, there are no breakages, just new deprecations — should *in theory* work — I don’t think anyone’s been testing it though
Bert: can this v8 release be supported for LTS? we don’t know if this is better or worse than 4.4? maybe ask goog eng
Trevor: they will say “Stay current”
Bert: I think I agree with them — with no other info, picking the latest version seems best
Michael: Z targets 4.4 — just recently got it fully clean — a move to 4.5 would cause a delay on getting release to community
James: that’s just Z, not PPC, yes?
Rod: how much work?
Michael: going 4.3->4.4 took about a month
Jeremiah: 4.3->4.4 breakage delta was much bigger
Rod: that’s the external API though
Michael: 7-8 patches/week? if we have to upgrade it will be extra work + delay for us
James: if we’re sitll looking at LTS in early-mid oct, it’s going to give us a month to prove out v8 4.5
Domenic: we’ve been proving out 4.5 for 12 weeks
Rod: we’re talking node here, though we’d have google support for an extra month. my concern is: we need v4 out now, latest by monday, this is a quick change and there’s potential for breakage
James: we decided before that we weren’t going to make such a big change so quickly before a release. i agree with rod, but such a big change makes me nervous — making sure that nan et al works with 4.5 is a concern
Jeremiah: we’re not going to be the ones to find the flaws in 4.5; want clarification on nan major/minor/patch?
Rod: minor
Domenic: should require no changes
Rod: benjamin (kkoopa) is on the positive side of this, he wants to see us move to 4.5, and is willing to put in the work to do this
Trevor: not that it matters much, but node has taken a hit from v8 in terms of perf recently, 4.5 has some improvements, fedor wrote an easily backportable patch as well, there are perf advantages
James: it makes me nervous that we’ll have enough time to test things on the node side before LTS — if we’re comfortable saying we have a plan that we think exercises this before going LTS, I’m more ok
Jeremiah: technically we have over a month
Rod: vote
who is leaning sticking to 4.4
James + michael + steven
4.5:
fedor, colin, jeremiah, brian, chris
Rod: clarifying concerns
Michael: share concerns with james, but also Z
Rod: longer we have to support our own V8, the harder it is, and another 6 weeks of support would be great great
James: I’m -0
Rod: spending some time today testing some existing addons taht have upgraded to nan@2. if there’s breakage, that tells me nan’s not ready, and that should be taken into account
Domenic: if nan’s not ready, we don’t upgrade
Rod: heading for 4.5, but with final go/no-go coming from nan testing; where are you at on this bert?
Bert: I am happy to upgrade if you land it and nothing changes — which sounds like it might be the case (sans deprecation warnings)
Rod: want ben’s opinion, but there may be no chance of that?
Bert: it seems silly to go with a version that is almost already out of support, but OTOH, on the scale of LTS lifetime, 6 weeks is not really significant
I wouldn’t worry too much about actual bugs in v8, about as likely in 4.5 as in 4.4; LTS is not about “no bugs”, it’s about “We support it”
Rod: we want a **solid** release, though
Bert: the LTS will also have a beta for a while, yes?
Rod: the beta period for LTS is the stable line
James: first LTS will have a beta of a little over a month, in the future 6 months
Bert: realistically a month is a longer beta than we’ve ever had before
Rod: 0.12 had a beta of 2 years
{zing} :trollface:
Bert: a beta with a lot of api changes, which is explicitly what we’re not going to do
Bert: we need to move on
Jeremiah: 4.5 brings arrow functions and that will make many people very happy
Rod: it’s a good sales pitch!
Rod: I’ll make the call.
### Node.js v4 Release Timeline [#2522](https://github.com/nodejs/node/issues/2522)
Rod: status update: v4 was to get out by Thurs, slipping on that, monday is the release date, cannot afford to slip any further
Jeremiah: what’s actually slipping other than mdb?
Rod: we’re not going to get mdb into v4, encourage before LTS, but that’s the best we can do, child process argument type checking where are we at on that?
Trevor: it’s not ready
James: working on that PR right now
Rod: great, that feels like a fairly light one, process.send is the other one; ben’s on holiday, where are we at with that pr of his
Jeremiah: multiple people have soft signed off on it
Colin: weren’t there some strange ci failures with it?
Rod: do not know, does someone want to put their hand up for that?
Trevor: what’s the PR number?
Jeremiah: #2620
Jeremiah: Trevor +1’d it
Jeremiah: OH! that’s the one with the weird test failures we could not reproduce the breakage
Rod: this seems like it can be run again and it won’t show flaky tests: maybe we should just re-run it
Trevor: that really sucks when you’re trying to land 3 tests
Rod: test runner should auto-rerun to make sure
Trevor: oh, gotcha
Rod: that’d be really quick for flaky tests
Trevor: I’ve already reviewed and LGTM’d it, I’ll look at running it through the land-ci job
James: looked at it earlier today, nothing concerning stood out
Rod: no RC’s are out! that’s a problem! we’ve renamed the executable. I wanted to have a period of time where folks could download (with a working node-gyp) — we need this period of time. I’ve been working on that, some bits and pieces to get things to the right place on the server. first build had a broken OS X installer. there are a few yaks yet to shave, so that’s why we can’t get this out by thursday
Rod: steven: could you confirm that 3.x has INTL enabled?
Steven: will look into, take as action item (confirmed!)
Rod: not going to tick that off till we confirm, but I _think_ that one’s done
Rod: how’s everyone with the timeline? rcs ASAP + release on monday
James: sounds reasonable, yes. will take as much time as possible on monday. several of us will be at nodeconf, so that complicates
Rod: I’m using monday in airquotes, it’ll be tuesday for me. other thing: smoke testing, citgm, I’ve been using it, and there are a lot of weird failures, after v4 we’re going to have to switch modes to make the ecosystem happy with it
Rod: let’s move ahead with that plan; nodeconf.eu is going to take up a lot of time for a lot of folk. congrats to everyone that contributed to new website, it seems really smooth
### Inspecting Node.js with Chrome DevTools [#2546](https://github.com/nodejs/node/issues/2546)
Rod: opened by member of v8 team, extracting debugger code from blink and making it so all embedded v8 projects can use it
Trevor: gist is: devtools team is considering pulling inspector out of blink into its own project so we could consume it; domenic can correct me wherever I’m wrong here,
Domenic: “making node work the same as android” able to point chrome dev tools at node processes to debug ‘em
???: only works with chrome
Trevor: OTW API we consume have remained fairly stable, even if the API does change, chrome dev tools is capable of pulling in a previous version, making sure it’s possible to use with LTS releases
OTW wire is generic, consumable by anyone, chrome dev tools is a key consumer, but anyone can consume (new consoles can compete!)
cons:
APIs going to need to be tightly integrated — needs to know about all async events
add conditionals to e.g. nextTick + timers
Domenic: add something to MakeCallback?
Trevor: we have to add it to that + on the way back in
Domenic: this is for async stack traces
Trevor: we don’t have to have it
Bert: that’s awesome, because we have to grow a single entry point (opposite MakeCallback)
Trevor: not going touch nextTick/timers, though — need to wrap each (because those APIs don’t roundtrip to C++ for each callback)
Bert: we don’t have to do that immediately though, but eventually it’d be a good idea
Domenic: could also move to microtask for nexttick — integrating with domains sounds hard, then we get those events for us
Trevor: would you be able to do unhandledRejections?
Domenic: we already have this for promises
Rod: if we could use this as a good justification for removing domains, that’d be awesome
Trevor: next point is pro and con: importantly, we’d have to support websockets natively in node
Jeremiah: we could just keep ‘em private
Trevor: that would just anger people
Domenic: you could bundle them and hide them while you’re not clear on the api, iterate and expose later
Rod: that’s a good point
Trevor: the interesting flip to this: they need to be running off the main thread, in a debugger thread — it can all be written in C++
mscdex: any way to avoid websockets?
Trevor: no
Bert: is the protocol really that complicated? I don’t think so — especially sans full HTTP and WSS — just websockets though is probably not difficult
Trevor: necessary because it’s the protocol that chrome dev tools uses
Rod: decision points: are we being asked to get on board?
Trevor: them removing the inspector from blink depends on whether we’ll use it if they do it.
Rod: debugging in node sucks, we are shipping with substandard debugging in v4, we don’t have the contributors + collaborators to make this better, so if we can lean on v8 to do this, I’m +1
debugging is important enough to override “small core”
Bert: we’re not adding the full inspector, _just_ the protocol
Trevor: wasn’t completely clear on how much API we’d need to implement
Domenic: we should get clarification on this
Trevor: if we can implement this in segments — if we’re all +1 on this, we need to create a new isolate, but …
Domenic: would the workers pr solve this?
Trevor: probably overkill. I’m +1 on the debugger
Bert: I propose we don’t vote
{broad assent}
Rod: trevor + domenic: you’ve got enough input
Domenic: only worry is finding someone to devote some of their daytime hours to implement websockets
Rod: nodesource could contribute, related to our interests
Trevor: even if we don’t say yes today, taking inspector out of blink is a complicated process and will take time
Rod: anything else?
### Next Meeting
September 9th

116
doc/tsc-meetings/2015-09-16.md

@ -1,116 +0,0 @@
# Node Foundation TSC Meeting 2015-09-16
## Links
* **Audio Recording**: https://soundcloud.com/node-foundation/tsc-meeting-2015-09-16
* **GitHub Issue**: https://github.com/nodejs/node/issues/2898
* **Minutes Google Doc**: https://docs.google.com/document/d/1RCR2pGOc2d80NNusaX5DZaktWvHEsDUqfEZP-tvexBk
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/1rXBdtsD9PJTExNXgzNZ9bez9oOjW45kLPjun4zdt0dY>_
## Present
* Rod Vagg (TSC)
* Brian White (TSC)
* Steven R Loomis
* Fedor Indutny (TSC)
* Bert Belder (TSC)
* Colin Ihrig (TSC)
* Trevor Norris (TSC)
* Shigeki Ohtsu (TSC)
* Chris Dickinson (TSC)
* Jeremiah Senkpiel (TSC)
* Ben Noordhuis (TSC)
* Alexis Campailla (TSC)
* Domenic Denicola
* Michael Dawson
## Agenda
Extracted from **tsc-agenda** labelled issues and pull requests in the nodejs org prior to meeting.
### nodejs/node-v0.x-archive
* Deprecate Array#values() in 0.12.x [#25877](https://github.com/nodejs/node-v0.x-archive/issues/25877)
* Deprecate smalloc in v0.12 [#25784](https://github.com/nodejs/node-v0.x-archive/issues/25784)
### nodejs/node
* Inspecting Node.js with Chrome DevTools [#2546](https://github.com/nodejs/node/issues/2546)
* util: Remove p, has been deprecated for years [#2529](https://github.com/nodejs/node/pull/2529)
## Minutes
Due to IBM’s acquisition of StrongLoop, IBM is over the TSC 25% company limit rule. Michael Dawson and Steven Loomis have stepped down from TSC, but they are here as observers.
### Standup
* Rod Vagg: Released 4.0.0, also 3.3.1 maintenance release. Getting the build system ready for building/publishing 0.10 and 0.12 binaries.
* Brian White: not much, triaging issues and PRs, some work on dns parser
* Steven R Loomis: tsc resignation for IBM/SL merge, some issue triage, working on a more robust download for ICU (ICU server was overloaded, fixed to ICU again redirects to sourceforge, discussed longer term discussions)
* Fedor Indutny: v8’s ArrayBuffer fixes, reviewing PRs, fixing issues
* Bert Belder: very few reviews/issue comments. Some libuv work on rwlocks.
* Colin Ihrig: not much, some issue tracker work
* Trevor Norris: Trying to make things (including Buffers) faster, some issue/PR review
* Shigeki Ohtsu: Just a few reviews of issues.
* Chris Dickinson: Working on shoving static npm analysis data into a database, slowly
* Jeremiah Senkpiel: NodeConf.eu, issues and PRs, 4.1.0 release
* Ben Noordhuis: only PR review and responding to bug reports, a patch or two upstreamed to v8
* Alexis Campailla: ARM cross-compile for CI. Misc fixes for VS 2015 / Win10
* Domenic Denicola: some issue and PR review, talking with v8 team
* Michael Dawson: landed the build updated for AIX, also updating the tests for AIX where necessary. Looking into PPC failures. Working on getting us hooked into v8 security notifications.
### Previous meeting’s agenda
* Jenkins merge jobs always overwrites PR-URL and Reviewed-By [#179](https://github.com/nodejs/build/issues/179)
* doc: update COLLABORATOR_GUIDE [#2638](https://github.com/nodejs/node/pull/2638)
* deps: update v8 to 4.5.103.30 [#2632](https://github.com/nodejs/node/pull/2632)
* Node.js v4 Release Timeline [#2522](https://github.com/nodejs/node/issues/2522)
* Inspecting Node.js with Chrome DevTools [#2546](https://github.com/nodejs/node/issues/2546)
### Deprecate Array#values() in 0.12.x [#25877](https://github.com/nodejs/node-v0.x-archive/issues/25877)
### Deprecate smalloc in v0.12 [#25784](https://github.com/nodejs/node-v0.x-archive/issues/25784)
Jeremiah: Are these things that we think we can do? Should we go ahead with that? Is it a good idea to deprecate these things?
Ben: How are we going to deprecate? Literal `util.deprecate`?
Jeremiah: Probably?
Trevor: They’re already floating a patch
Rod: I’m fine with deprecating smalloc
Trevor: Is there a deprecation cycle between LTS? I’m not sure how this would work? (i.e., if we deprecate now, LTS -> LTS upgraders will not see a deprecation warning.)
Rod: Maybe punt to LTS WG? It could be quite a lot — it could be that we decide between stable versions to remove things (or we’re forced to), do we backport the deprecation to LTS?
Jeremiah: I think it should be only for things we’re _forced_ to remove
Action: Punt to LTS WG
### Inspecting Node.js with Chrome DevTools [#2546](https://github.com/nodejs/node/issues/2546)
Trevor: Have an 80% understanding of the work needed: WebSocket support in core (though not necessarily exposed publicly), API injection points. Are we ok with including web sockets support one way or another?
Rod, Domenic, others: +1
### util: Remove p, has been deprecated for years [#2529](https://github.com/nodejs/node/pull/2529)
Discussion of Buffer “raw{s,}” encoding as well — undocumented, deprecated, inconsistently implemented in core.
Action: Remove util.p (Jeremiah to respond.)
Bert: Perhaps we should bulk remove?
Rod: util.p is relatively trivial, has a deprecation warning, etc.
Jeremiah: Brought this up because these things have been deprecated forever. util.exec has been deprecated for a while, as well.
Trevor: raw/raws are deprecated in name only, no warnings, but C++ layer does not know about them (falls back to utf8) — maybe should be removed as a bugfix, because it does not work consistently.
Action: Chris to list “least used stuff” (with apologies for how longs its taken!)
### Next Meeting
September 23

161
doc/tsc-meetings/2015-09-30.md

@ -1,161 +0,0 @@
# Node Foundation TSC Meeting 2015-09-30
## Links
* **Audio Recording**: https://soundcloud.com/node-foundation/tsc-meeting-2015-09-30
* **GitHub Issue**: https://github.com/nodejs/node/issues/3126
* **Minutes Google Doc**: https://docs.google.com/document/d/1RkLAWTIrhD3BTB2rs9_FahWI0C7lt9F8xnQXaueJPIE
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/1RCR2pGOc2d80NNusaX5DZaktWvHEsDUqfEZP-tvexBk>_
## Present
* Rod Vagg (TSC)
* Brian White (TSC)
* Chris Dickinson (TSC)
* James Snell (TSC)
* Michael Dawson
* Ben Noordhuis (TSC)
* Steven R Loomis
* Bert Belder (TSC)
* Alexis Campailla (TSC)
* Domenic Denicola
* Seth Thompson
## Agenda
Extracted from **tsc-agenda** labelled issues and pull requests in the nodejs org prior to meeting.
### nodejs/node
* Discussion: LTS & v5 release planning [#3000](https://github.com/nodejs/node/issues/3000)
* Inspecting Node.js with Chrome DevTools [#2546](https://github.com/nodejs/node/issues/2546)
### nodejs/TSC
* Umbrella Program [#2](https://github.com/nodejs/TSC/pull/2)
## Minutes
### Standup
* Rod Vagg (TSC) - Lots! Pass.
* Brian White (TSC) - DNS PR (querying NSS modules like mDNS works now, continuing work on other getnameinfo/getaddrinfo compat issues)
* Chris Dickinson (TSC) - Static Analysis
* James Snell (TSC) - Review of the HTTP module, going in depth with spec compliance
* Michael Dawson - AIX, contributing changes from IBM repos, node-gyp, all related to getting native modules working on AIX, submitted PR to core, benchmarking — bare metal machine for benchmarking group, backporting test fix to 0.12, FIPS-compat work on the test suite, getting hooked into v8 security reporting
* Ben Noordhuis (TSC) - Review PRs, bug reports, fixed 1-2 bugs, sent a few patches upstream to V8 and gyp, fixed a few bugs in node-gyp.
* Steven R Loomis - Review PRs, bug reports. Looking into alternatives to packaging full ICU data. Might be able to `npm install` ICU data.
* Bert Belder (TSC) -
* Alexis Campailla (TSC) - working on Node-serialport on Windows in Jenkins, looking into native module build service
* Domenic Denicola - v8-extras are starting to appear in Chrome, maybe use them in Node for startup performance.
### Review of previous meeting
* Deprecate Array#values() in 0.12.x [#25877](https://github.com/nodejs/node-v0.x-archive/issues/25877)
* Deprecate smalloc in v0.12 [#25784](https://github.com/nodejs/node-v0.x-archive/issues/25784)
* Inspecting Node.js with Chrome DevTools [#2546](https://github.com/nodejs/node/issues/2546)
* util: Remove p, has been deprecated for years [#2529](https://github.com/nodejs/node/pull/2529)
### Discussion: LTS & v5 release planning [#3000](https://github.com/nodejs/node/issues/3000)
(Chris: apologies, I did a bad job here.)
Ben: Plan is to ship the first LTS release with v8 4.5, not 4.6
Rod: Yes.
Ben: Is there a pressing reason to do so?
Rod: LTS comes off the v4.x branch, we committed to not bump V8 in stable releases.
Ben: It basically means that the first LTS release is going to ship with an outdated release.
James: Yes, we knew this was a strong possibility.
Michael: The model is that we give the community time to catch up. In the future that’s 6 months, so we’re never going to be on a supported version.
Ben: V8 moves quickly. If we stick with 4.5, we’re going to have to manage a bigger delta between our copy and upstream.
James: Yes, this was always going to be the case. We’re committed to supporting the V8 for 36 months.
Ben: Yes, my point is that we could be starting with a smaller delta.
Rod: One of the reasons we had this LTS delay on 4 is to shake out some of these concerns, like the buffer changes. Normally this shakeout will be 6 months, but this time it’s only been a month.
Alexis: Is v5 going to be LTS also?
Rod: We are having discussions about the overlap between v5 and v6, whether there’ll be a strict cutoff or some overlap. No decision yet. That’ll happen in April. It sounds like most folks are leaning towards
making the two releases (v4 LTS + v5) independent — option 1 [here](https://github.com/nodejs/node/issues/3000#issuecomment-144026295).
Ben: We still haven’t come up with a way to maintain V8 going forward.
James: We do need a good process there, you are absolutely right about that.
Rod: I vote for IBM to hire someone dedicated to this. (Laughter)
Michael: I can’t promise that at this point.
Rod: As the delta increases between versions this becomes more concerning.
James: make sure this is on the LTS WG agenda for next week.
Rod: We tried to tackle this once before, came up with job description but nothing concrete.
Michael: We stopped short of telling the foundation that this is a position that we need to staff.
James: I would agree. We’re at the point where bringing someone in at the foundation level is probably a good idea.
Rod: Noted. OK. We’ve got resolution there.
Michael: James: Make sure it’s on the LTS agenda for going back to the foundation for resources.
Rod: LTS is meeting this Monday (issue 43 on the repo). There’s some discussion around codenames and how to expose LTS info. We’ve committed to first week of October for LTS releases, so timing is going to be a little awkward with 4.1.2 coming out monday. Version 5 will be shipping when we have a stable V8, presumably mid-to-late october (1-3 weeks with no stable release line.)
Rod: We’ll be pulling in semver minor and patch changes, we’ll continue to have bugfix releases for version 4,
### Inspecting Node.js with Chrome DevTools [#2546](https://github.com/nodejs/node/issues/2546)
Rod: Trevor is lead on this, but isn’t present. Does anyone else have any updates?
Ben: Wasn’t the last contentious issue putting WS in core? I think we agreed that if it’s not exposed to user-land, it's fine.
Alexis: (discussion of another WS issue)
Bert: we decided on this
Ben: We agreed that if it was internal, non-exposed to core,
(Talk about native deps for WS, buffer-util can be )
Ben: if this is a private dependency, we don’t need it to be fast, so we don’t necessarily need the native deps.
Chris: (Hopped into discussion from minute-taking, hence the bad minutes)
https://github.com/nodejs/node/pull/1202 - add mask/unmask
https://github.com/nodejs/node/pull/1319 - add utf8 validator
### Umbrella Program [#2](https://github.com/nodejs/TSC/pull/2)
Ben: it’s basically a template for describing projects that are under the umbrella of the node foundation. It doesn’t look that controversial to me.
Rod: it also doesn’t look that complete.
Ben: Indeed. I suggest we discuss next week when mikeal is on the call. Seems like a rubber-stamp LGTM to me.
Rod: We should think about what projects we want to introduce to the organization, including what happens to competition in the ecosystem when we pull in things (like build tools)
Domenic: This is for things like libuv, yes?
Rod: There are already npm projects knocking on the door. One such project is request. It has its own org right now, but could work under the auspices of the node foundation. However it exists in an ecosystem where there is competition — is it okay for us to bless one project over others? NAN is sort of in the same position, it _could_ have competition. Another example is the npm client possibly. If the foundation were in a position to take npm would we even want it?
### renaming of “language groups” from iojs-\* to nodejs-\* [#2525](https://github.com/nodejs/node/issues/2525)
Steven: Looking for buyoff on this.
Ben: Seen the approach and it looks good.
Rod: You should take this as “you have authority to move ahead”.
Steven: Will do.
### Next Meeting
October 7th

102
doc/tsc-meetings/2015-10-07.md

@ -1,102 +0,0 @@
# Node Foundation TSC Meeting 2015-10-07
## Links
* **Audio Recording**: https://soundcloud.com/node-foundation/tsc-meeting-2015-10-07
* **GitHub Issue**: https://github.com/nodejs/node/issues/3126
* **Minutes Google Doc**: https://docs.google.com/document/d/1LIrTCdTUjKtb_GGecrJ3Es0rPOpVdpkV5kefJ_p5FGU
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/1RkLAWTIrhD3BTB2rs9_FahWI0C7lt9F8xnQXaueJPIE>_
## Present
* Rod Vagg (TSC)
* Brian White (TSC)
* Steven Loomis (observer)
* Trevor Norris (TSC)
* Shigeki Ohtsu (TSC)
* Ben Noordhuis (TSC)
* Mikeal Rogers (observer)
* Michael Dawson (observer)
* Seth Thompson (observer)
* Jeremiah Senkpiel (TSC)
## Agenda
Extracted from **tsc-agenda** labelled issues and pull requests in the nodejs org prior to meeting.
### nodejs/node
* WG: Considering a new HTTP WG [#3214](https://github.com/nodejs/node/issues/3214)
* lib,test: deprecate _linklist [#3078](https://github.com/nodejs/node/pull/3078)
* Discussion: LTS & v5 release planning [#3000](https://github.com/nodejs/node/issues/3000)
* Compiling node v4.0.0 with OpenSSL 1.0.1 fails [#2783](https://github.com/nodejs/node/issues/2783)
* Inspecting Node.js with Chrome DevTools [#2546](https://github.com/nodejs/node/issues/2546)
### nodejs/TSC
* Umbrella Program [#2](https://github.com/nodejs/TSC/pull/2)
## Minutes
### Standup
* Rod Vagg: 4.1.2 release, security procedures surrounding that
* Brian White: Working on javascript dns resolver, regular PR + Issue work.
* Steven Loomis: Working on ICU 56 Release. TC 39 & emca spec work for Intl WG. Working on Intl build issues.
* Trevor Norris: Focused on fixing async_wrap, writing tests and preparing for it to become more official
* Shigeki Ohtsu: No works for node project, I spent all time to my internal works.
* Ben Noordhuis: Nothing to report—the usual
* Mikeal Rogers: Looking into stalled Wgs and seeing how to help out. Working on the umbrella program. Lots of conference things.
* Michael Dawson: Added a benchmarking machine to the CI, working on some tests issues. Working on PPC for the CI.
* Seth Thompson: Working on v8 4.7, scheduled soon
* Jeremiah Senkpiel: vacation, some issue catch-up
### Review of previous meeting
* Discussion: LTS & v5 release planning [#3000](https://github.com/nodejs/node/issues/3000)
* Inspecting Node.js with Chrome DevTools [#2546](https://github.com/nodejs/node/issues/2546)
* Umbrella Program [#2](https://github.com/nodejs/TSC/pull/2)
* renaming of “language groups” from iojs-\* to nodejs-\* [#2525](https://github.com/nodejs/node/issues/2525)
### WG: Considering a new HTTP WG [#3214](https://github.com/nodejs/node/issues/3214)
* Discussed the HTTP WG based on James’ comments @ https://github.com/nodejs/node/issues/3234#issuecomment-146293038
* Generally positive, only concerns are regarding decision making power—TSC may not want to hand that off as this is not quite like Streams (in that few people grok the code!) and there are philosophical questions to be resolved about HTTP that the TSC should be involved in.
### lib,test: deprecate _linklist [#3078](https://github.com/nodejs/node/pull/3078)
* Userland modules exist that could be used instead
* Ben suggested straight removal, Jeramiah raised the matter of process that we have committed to adding a warning before removal, so we could remove in v6 but probably shouldn’t in v5
* No disagreement with moving forward for deprecation
### Discussion: LTS & v5 release planning [#3000](https://github.com/nodejs/node/issues/3000)
* Recap of the latest LTS meeting [LTS#43](https://github.com/nodejs/LTS/issues/43)
* Aim to have LTS / v4.2.0 out tomorrow, backup date of Monday if we miss that. LTS starts then for v4.x, v5.x has to wait until V8 4.6 to be stable mid to late October.
### Compiling node v4.0.0 with OpenSSL 1.0.1 fails [#2783](https://github.com/nodejs/node/issues/2783)
* Shigeki, Ben: It would be quite hard to support 1.0.1 since we are using 1.0.2 APIs.
* Discussion on the possible difficulty of using 1.0.2 on varied Linux distros
* ubuntu wily (not released) seems to use 1.0.2 - work has been done to package. 1.0.2 is only in Wily - https://launchpad.net/ubuntu/+source/openssl/1.0.2d-0ubuntu1 - https://answers.launchpad.net/ubuntu/+source/openssl/+question/263725 - “My guess is that we will see openssl 1.0.2 from Ubuntu 15.10 onwards (or eventually only starting with 16.04)”
* Concern that allowing 1.0.1 would result in a substandard (insecure?) & untested binary.
* Some discussion about the fact that we don’t test building with shared / static dependencies
* feedback to issue: No appetite to do the work from the TSC, maybe someone could do it but we wouldn’t support.
### Inspecting Node.js with Chrome DevTools [#2546](https://github.com/nodejs/node/issues/2546)
_skipped discussion_
### Umbrella Program [#2](https://github.com/nodejs/TSC/pull/2)
_skipped discussion_
## Next Meeting
October 14th, 2015

121
doc/tsc-meetings/2015-10-14.md

@ -1,121 +0,0 @@
# Node Foundation TSC Meeting 2015-10-14
## Links
* **Audio Recording**: https://soundcloud.com/node-foundation/tsc-meeting-2015-10-14
* **GitHub Issue**: https://github.com/nodejs/node/issues/3363
* **Minutes Google Doc**: <https://docs.google.com/document/d/1tVPxA4Y3n3dmICJFZN2vK93PXjCaUQ-eiN2mvt7zqbE>
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/1LIrTCdTUjKtb_GGecrJ3Es0rPOpVdpkV5kefJ_p5FGU>_
## Present
* Rod Vagg (TSC)
* Domenic Denicola (observer)
* Brian White (TSC)
* Steven Loomis (observer)
* James Snell (TSC)
* Michael Dawson (observer)
* Ben Noordhuis (TSC)
* Jeremiah Senkpiel (TSC)
* Trevor Norris (TSC)
* Alexis Campailla (TSC)
* Mikeal Rogers (observer)
## Agenda
Extracted from **tsc-agenda** labelled issues and pull requests in the nodejs org prior to meeting.
### nodejs/node
* V8 security reporting [#3348](https://github.com/nodejs/node/issues/3348)
* doc: add information about Assert behavior and maintenance [#3330](https://github.com/nodejs/node/pull/3330)
* WG: Considering a new HTTP WG [#3214](https://github.com/nodejs/node/issues/3214)
* Discussion: LTS & v5 release planning [#3000](https://github.com/nodejs/node/issues/3000)
* Compiling node v4.0.0 with OpenSSL 1.0.1 fails [#2783](https://github.com/nodejs/node/issues/2783)
### nodejs/TSC
* Umbrella Program [#2](https://github.com/nodejs/TSC/pull/2)
## Minutes
### Standup
* Rod Vagg: Not quite as involved, took a bit of time off. Getting back up to speed on build
* Domenic: Nothing this week
* Brian: PRs & Issues
* Steven: Worked on getting ICU 56.1 out and into v4.2.0 LTS, working on making the ICU [install better](https://github.com/nodejs/node-v0.x-archive/issues/8996#issuecomment-89411193). Also shepherding iojs-\* rename to nodejs-\* [#2525](https://github.com/nodejs/node/issues/2525)
* James: Worked on the 4.2.0 and 4.2.1 releases. Working on the cgitm smoke-testing tool and http WG.
* Michael: Worked on adding pLinux to the CI. Looking into running the tests on fips-compliant mode. Investigated some AIX issues.
* Ben: PRs & Issues, doing some work on the debugger and memory bugs in libuv
* Jeremiah: PRs & Issues, working on resolving the timers in beforeExit bug: https://github.com/nodejs/node/pull/2795
* Trevor: Helped Jeremiah with the beforeExit thing, worked on PRs and Issues. Looking into AsyncWrap improvements.
* Alexis: Looking into a native module build service. Worked on the Ci a bit.
* Mikeal: Worked on the Umbrella Program proposal. Helping set up the Node.js Interactive conference.
### Review of previous meeting
* WG: Considering a new HTTP WG [#3214](https://github.com/nodejs/node/issues/3214)
* lib,test: deprecate _linklist [#3078](https://github.com/nodejs/node/pull/3078)
* Discussion: LTS & v5 release planning [#3000](https://github.com/nodejs/node/issues/3000)
* Compiling node v4.0.0 with OpenSSL 1.0.1 fails [#2783](https://github.com/nodejs/node/issues/2783)
* Inspecting Node.js with Chrome DevTools [#2546](https://github.com/nodejs/node/issues/2546)
* Umbrella Program [#2](https://github.com/nodejs/TSC/pull/2)
### V8 security reporting [#3348](https://github.com/nodejs/node/issues/3348)
Michael: Proposal is to add one or more TSC members to the V8 security list. Not all issues will actually be V8 issues, but there shouldn’t be too many.
* Concerns about too many issues
Michael: Let’s go back and ask if a handfull means only 4-5 a week.
Mikeal: Part of the Umbrella Program is to make a top-level security group that all security issues are funneled through. This group may not need to be TSC members.
Ben: How would this group know an issue is relevant to us?
Rod: We are talking about a Chromium security list, so we would probably need someone with enough knowledge to filter out which issues affect us.
Mikeal: They would only be an initial filter.
Rod: Some chromium issues will not be recognizable as V8 issues without prior understanding.
Rod & others: Suggest to add Ben and Fedor to add to the Chromium/V8 security list.
Discussion about the current Security repo / group, and current mailing lists
### doc: add information about Assert behavior and maintenance [#3330](https://github.com/nodejs/node/pull/3330)
Discussion about what assert is intended to do, and how we want to deal with additions and breaking changes in the future.
Discussion about the stability index in the docs.
Resolution: Lock the assert module. Possibly re-evaluate in the future. Close existing open PRs/issues against it after landing doc change.
### WG: Considering a new HTTP WG [#3214](https://github.com/nodejs/node/issues/3214)
James: having scheduling problems for an initial hangout but are getting a lot of interest from outside of core, including Doug Wilson and Eran Hammer.
Discussion about the WG’s goals and how we should possibly think about handing over authority of the http module to this WG in the future. (At charter time or later on)
### Discussion: LTS & v5 release planning [#3000](https://github.com/nodejs/node/issues/3000)
James: recommended that we adopt a general rule that commits must go through at least one stable release before going into an LTS. Exceptions to this are security problems and changes that can’t go on to stable.
### Compiling node v4.0.0 with OpenSSL 1.0.1 fails [#2783](https://github.com/nodejs/node/issues/2783)
Conclusion was that this would be difficult and would result in a build that had some features disabled. The TSC is not going to undertake this work and would have reservations officially supporting a build that cripples some crypto features. However, pull requests for this work are welcome and would be considered.
### Umbrella Program [#2](https://github.com/nodejs/TSC/pull/2)
Mikeal sought a vote from the TSC to adopt the Project Lifecycle document and the Core TLP document.
Resolution: there were no abstentions from voting and no disagreement amongst TSC members present, additional TSC members have registered their +1 on the PR so the motion is passed.
## Next Meeting
October 21st, 2015

214
doc/tsc-meetings/2015-10-21.md

@ -1,214 +0,0 @@
# Node Foundation Core Technical Committee (CTC) Meeting 2015-10-21
## Links
* **Audio Recording**: https://soundcloud.com/node-foundation/tsc-meeting-2015-10-21
* **GitHub Issue**: https://github.com/nodejs/node/issues/3464
* **Minutes Google Doc**: <https://docs.google.com/document/d/1ad8Xlza_B-iWexdlAd1Z5muzBy_HH88t_iSD31OUepA>
* _Previous Minutes Google Doc: <https://docs.google.com/document/d/1tVPxA4Y3n3dmICJFZN2vK93PXjCaUQ-eiN2mvt7zqbE>_
## Present
* Rod Vagg (CTC)
* Brian White (CTC)
* Steven R. Loomis (observer)
* James Snell (CTC)
* Michael Dawson (observer)
* 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)
## Agenda
Extracted from **tsc-agenda** labelled issues and pull requests in the nodejs org prior to meeting.
### nodejs/node
* 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)
## Minutes
### Review of previous meeting
* V8 security reporting [#3348](https://github.com/nodejs/node/issues/3348)
* doc: add information about Assert behavior and maintenance [#3330](https://github.com/nodejs/node/pull/3330)
* WG: Considering a new HTTP WG [#3214](https://github.com/nodejs/node/issues/3214)
* Discussion: LTS & v5 release planning [#3000](https://github.com/nodejs/node/issues/3000)
* Compiling node v4.0.0 with OpenSSL 1.0.1 fails [#2783](https://github.com/nodejs/node/issues/2783)
* Umbrella Program [#2](https://github.com/nodejs/TSC/pull/2)
### Standup
* Rod Vagg: index.tab and index.json updates (nodejs.org/dist/index.*) including an “lts” field, also made consistent directories for ancient Node tarballs with shasums files so nvm and other tools can simplify their access. v5 and other build yak shaving.
* Brian White: usual triaging and PR and Issues commenting, not much else
* Steven R. Loomis: Intl meeting, "full-icu" npm module [will be away until Nov 11 meeting, Unicode conf/Unicode-TC]
* James Snell: Working on localization for the node runtime [#3413](https://github.com/nodejs/node/pull/3413)
* Michael Dawson: Working through PPC and AIX PRs and issues, LTS WG discussions, Benchmarking WG, working with Stefan on agenda items for API WG meeting.
* Chris Dickinson: was busy with vacation and conferences, but looking into the WhatWG Streams spec, next up is static analysis server
* Ben Noordhuis: The usual. Looking into make the debugger better. The test suite is in bad shape
* Jeremiah Senkpiel: issue and PR work — going back through the backlog now, helping with v5 release + npm@3
* Trevor Norris: flurry of AsyncWrap PRs, trying to get it to a point where people could more reliably use it, it can’t be hidden forever.
* Alexis Campailla: Sick, traveling; CI progress on flakiness, some progress on native module build service
* Mikeal Rogers: Foundation resources for v5 release: PR folks wrote a blog post, expectation setting, make sure enterprises are still using LTS, if you’re a dev here’s what to be excited about, etc.
* Shigeki Ohtsu: Worked semver-major fix to limit DH key size [#1831] (https://github.com/nodejs/node/pull/1831) and some works for root certs.
* Seth Thompson: Security mailing list stuff went through this week, working on v8 side of things to create a new version of the octane benchmark, excited about the benchmarking WG
* Bert Belder: nothing
* Fedor Indutny: reviewing PRs, helped fix a beforeExit bug, fixing yet another V8’s ArrayBuffer issue
- Discussed the ArrayBuffer issue in detail
* (Aside: Shigeki and Fedor were asked to look at [#3406](https://github.com/nodejs/node/issues/3406) - “p1/p2” issue )
### governance: add new collaborators #VIII [#3472](https://github.com/nodejs/node/issues/3472)
- Discussed onboarding.
- Action: Jeremiah to schedule and run another onaboarding, Chris to tune in.
### detect "full-icu" module [#3460](https://github.com/nodejs/node/issues/3460)
Stems from conversation from the 0.X days about whether Node should ship other languages separately.
This is a module published on npm as an alternative to shipping with Node proper.
Whether node can detect a full-icu install in a special place (node_modules/full-icu, global/node_modules/full-icu)
Nathan7 commented with a concern about coupling npm to node
Currently have to start node with ICU_DATA_PATH=some/path/to/file
Rod: Couple it to `execPath`
James: globally installed could install into a well known global location
Rod: Does this have to be done at startup?
Stephen: Yes. V8 has to have the data available before starting.
James: Happens right after parsing args
Rod: Could use HOME?
Stephen: Could use NODE_PATH?
Rod: Trying to move away from NODE_PATH
Ben: Might just bite the bullet and include ICU?
Stephen: I would like that, but I am sympathetic to folks running on OpenWRT
Ben: I can see that, but all this installing in special paths leaves a lot of margin for error.
James: Full ICU will double the size of the Node binary. Hard pill to swallow.
Rod: We could offer alternative downloads?
Stephen: Two downloads would work as well. We could do this all from build infra.
Bert: I would not be in favor of that. We end up with “oh my module doesn’t work” “oh you didn’t download the right flavor of Node”
Jeremiah: It’s going to make it confusing no matter what
... [I missed this]
Chris: could we offer better error messages?
Rod: it peeks through in a lot of places — the ICU object, strings, etc. Maybe best to leave to module authors? Include a process.versions.icu object?
James: small-icu is the default build running locally — CI doesn’t run with ICU enabled?
Trevor: even if small-icu is there, it means less data, but not less build time. I would like to see how that affects the raspberry pi’s build time.
Ben: we could avoid rebuilding ICU on rasppis
Stephen: or use a precompiled ICU
Jeremiah: Assumes an internet connected machine
Rod: If we go with small-icu we should make it available
Ben: should we add it to the repo?
Alexis: I think so, it’s causing problems
[???]: It’s about 80mb
Rod: How big is it?
Stephen: The source size & binary size was comparable to Node.
We could have a non-standard source checked in.
Mikeal: we could use the large file storage stuff GH just added.
Stephen: 25mb uncompressed, 130mb for source tree
Mikeal: if we say “you need ICU to build” we need to make it available
Trevor: How’s this going to work with bouncing between branches?
Alexis: What about keeping it as text?
Ben:
Steven: We have a 25mb compressed zip of source, that itself contains a 25mb compressed zip. We could strip that down — what would it take to delete the tests, etc — a subset
Mikeal: so could we just install this 25mb file?
Rod: This adds a dep on Git LFS
Mikeal: Let’s try to solve one problem at a time — fix downloading, not making the default
Rod: I’m happy with how the CI does it
Stephen: The first time you hit something ICU-based it loads it.
Rod: I’m just wondering if this could be turned into a proper npm module.
Stephen: I’m not sure — it looks pretty deeply enmeshed into V8
Seth: I don’t have answers off the top of my head on that one, I responded on the thread; we don’t currently have a priority to mess
around with localization. If there’s a design doc that proposes cleaning things up we’d be interested
James: Resource bundle mechanism — [Note: didn’t get all of this] “using the same startup sequence as Intl.. so needs to be configured at start time” (https://github.com/nodejs/node/pull/3413 uses ICU’s resource bundle mechanism, which uses the same init path as the core data. ICU does not allow multiple initializations.
Alexis: If the only reason we’re trying to package it is to use npm to install it, maybe we’re complicating this unnecessarily
Rod: On the iojs side we decided not to go with ICU. It’s in core because it has to be initialized before v8 is started, my question is this something that could be changed upstream in v8? Ideally this should not be in core.
Steven: It didn’t look like it could be split off easily.
Chris: JS proxies
Steven: Possible, but _very_ tricky
[Moving conversation to GH]
### WG: Considering a new HTTP WG [#3214](https://github.com/nodejs/node/issues/3214)
HTTP WG first meeting is tomorrow at 1pm Pacific, nothing to discuss yet
### node: deprecate public access to `process.binding` [#2768](https://github.com/nodejs/node/pull/2768)
Lots of discussion, focused on `process.binding('natives')`. Summary: We should at least try to make it read-only first. Ben said he would follow up with a PR.
### node: make listen address configurable [#3316](https://github.com/nodejs/node/pull/3316)
Fedor: Ben suggested commandline argument to submit hostname and port. Fedor concerned about the amout of code required to parse and separate the two parts of the option. Would be better to have a separate argument for hostname.
Discussion about usability vs simplicity of code.
Quick vote on whether to move forward with the PR in its current form, no objections.
## Next Meeting
October 28th, 2015

61
doc/tsc-meetings/io.js/2014-10-09.md

@ -1,61 +0,0 @@
- Contribution Policy was merged last week.
- Concerns about https://github.com/node-forward/node/issues/2 have been brought
up, it effects almost every line and will make merges with Joyent
unnecessarily painful in the short term. The consensus was to put it on the
back burner.
- It's a little difficult to work in the fork at the moment:
- It's hard to contextualize what to fix without having a release in mind
- We'll start doing source-only releases ASAP so that we can create a work
scope.
- Someone will be in charge of keeping their head around and driving each
release. This should probably rotate, Bert will take on the first one with
the goal of releasing before the end of the month.
- For now tagging will create a GitHub "release." Eventually the build infra
can attach binary installers to that GitHub release.
- It's hard to keep a list of issues that are being tackled from the backlog
in joyent's repo
- Bert will maintain a list of TODO checkbox items in a GitHub Issue for a
release the references the PRs and Issues in Joyent's repo. We'll also be on
the lookout for other tools that might make this easier.
- The build stuff is coming up a lot and the discussion about how releases work
should include someone from the build project.
- Invite whoever is leading the build effort (current @rvagg) to the TC meeting
to participate (non-voting).
- Eventually we'll need a better support structure where community members can
triage issues and respond to all the incoming requests.
- @mikeal created a "community" group and a repo for larger community issues.
Once there is some momentum there we can bring problems like this to the
community but the repo we currently control write access to doesn't have all
of the issues in it so this can wait.
- @indutny suggested a bot that auto-responds. @isaacs thought an
autoresponder was a little inhuman. It was agreed that the best thing to do
is have a bot that comments on the issue *once a tag is added* that is
specific to that tag and run in concert with humans tagging issues.
- @piscisaureus really wants to find a way for him to tell if someone already
looked at an issue so that him, trevor, ben, and fedor don't independently
look at every issue.
- @indutny wants to get a newer v8 in. this work is slated to be finished for
the first release.
- @trevnorris mentioned that there are some new features in v8 that we may
want to use to replace certain parts of node down the road.
- @trevnorris and @isaacs want a "commit script" that people can run which
automates a lot of the manual cleanliness we currently require for all commits.
v8 has as simliar one. this will be written in javascript by @isaacs and
@trevnorris .
- When pulling in joyent/node commits we should use no-fast-forward commits.
- If people want to talk to the TC in a more "chatty" way we should use the
`#node-forward` IRC channel on freenode. We need to add logging.
- The video of TC meetings doesn't include the chat so we need to be aware of
that when using it during the calls.
Video of the call is https://www.youtube.com/watch?v=fNW_tu2QnpA

44
doc/tsc-meetings/io.js/2014-10-15.md

@ -1,44 +0,0 @@
# node-forward TC Meeting 2014-10-15
## Agenda
* Openssl upgrade / openssl 1.0.1j, disabling SSL3 support
* Status of the build system & release automation
* https://github.com/node-forward/node/pull/14 - refine TC percentage rules - CONTRIBUTING.md
* Items preventing node-forward from releasing v0.12.
* Node Forward release cycle/schedule.
* (Maybe discuss v8 3.29 in node-forward vs 3.28 in joyent/node, and merging them? ...just a suggestion)
* Performance situation
* Node Forward website, non-core stuff, help repo.
## Links
* **Google Hangouts Video**: https://www.youtube.com/watch?v=aRBuu2m5xbI
* **Original Minutes Google Doc**: https://docs.google.com/a/vagg.org/document/d/18l01PO2Rb3OZXWMcIkZ_sU4f1JKP2LKOwjuiENkg37M
## Minutes
### Present
* Rod Vagg (facilitator, build representative)
* Mikeal Rogers (facilitator)
* Ben Noordhuis (TC)
* Bert Belder (TC)
* Fedor Indutny (TC)
* Trevor Norris (TC)
### Discussion
* Fedor: **OpenSSL upgrade to 1.0.1j done in a branch**, build bots reporting OK, ready to merge. SSLv3 disabled completely in joyent/node 0.12 because the protocol is broken--attack comes from downgrade request from TLS to SSLv3. 0.10 has a runtime flag to enable it via process arguments (`--enable-ssl3`).
* Rod (representing the build group): tried Jenkins and BuildBot. Neither are great, but right now they’re working on getting something to work now, although eventually they’d like a great build system. There are build bots running for most platforms right now, except OS X (but there’s commitment from voxer to sponsor machines). Building branches works, but PRs doesn’t. This week some basic useful stuff should be available.
- https://github.com/graydon/bors - rust
- Benchmarks? Make a CI target just for benchmarks so we can track it over time. Not run on every PR, perhaps manually triggered, perhaps time triggered. http-simple? Fedor: large nightly benchmarks would be nice. Start with Linux, a single consistent box running the suite (doing a release too).
* **Refine TC percentage**: pull node-forward/node#14. TC is short two people without Joyent & is small. 2 of 6 people are from Strongloop. #14 allows changing to 33% to allow the current TC to not be in violation for the time being and then change it back to 20% when we can. Consensus has been relatively easy, no votes have been needed thus far so there isn’t much concern.
* **Release cycle**: time based releases? node-forward discussion have strong consensus for a desire to move to semver and also a quicker release cycle.
- **General agreement on semver**, minor releases backward-compatible, major releases can break.
- Discussion on **native API compatibility**, NAN or NAN-like or something more brave like having ABI compatibility. Ben: “You can’t forecast the future, the abstraction will break”.
- **Supporting old versions**: deal with it when the project has “prior releases”. Defer discussion on exactly the model until the project is ready to make proper releases. Move discussion to GitHub.
* **V8 3.29**, Fedor: joyent/node has 3.28, node-forward/node has 3.29. Trevor & Fedor agreed to put 3.29 in joyent/node pending agreement with TJ.
* **node-forward website**, Mikeal: there is a website, http://nodeforward.org/
- Forrest suggests a help repo to replace what the mailing list works, he has offered to help support that.

33
doc/tsc-meetings/io.js/2014-10-29.md

@ -1,33 +0,0 @@
* Update on Build
* @rvagg is working on getting the builds consistently green
before moving on to more complicated things.
* @issacs brought up the Joyent Advisory board
* Some confusion out there about Node Forward vs. Advisory Board
* @mikeal updated the messaging on the website to be clearer
* The website has clearer calls to action for the community
* Libuv move
* The libuv contributors want to move to the libuv org.
* @mikeal will email @indutny and other libuv contributors to ask them
to log an issue about this on their repo for transparency and so that
this is not a surprise to Joyent
* Update on "release buckets"
* doesn't make sense while we're private, we'll wait until it is public again
* `node-forward/node` going public
* when we made the repo private it was messaged as only being for "four weeks"
* "four weeks" is up on November 8th
* someone on the Advisory Board needs to remind Joyent of this in the
next advisory board meeting so they aren't suprised by it even though
it was communicated to them when it was first made public.
* @mikeal will work on the messaging in the README to make it clear this is
a "soft" fork and not a "hard" fork.
* ramifications of going public will be discussed in next week's TC meeting as
well
* @mikeal proposed a change in TC meeting process
* it's impossible to schedule all the timezones involved in every meeting
* every Monday create a "Weekly TC Agenda" Issue people can contribute to
* the TC members who care about that Agenda will state they want to be in the
meeting
* @mikeal will work to schedule the TC members who care for a hangout
* people are using and liking gitter
* we'll consider moving from IRC to gitter once the repo is public again
* yes, gitter has IRC integration (you can login to gitter from an IRC client)

139
doc/tsc-meetings/io.js/2014-12-10.md

@ -1,139 +0,0 @@
# io.js TC Meeting 2014-12-10
## Agenda
Extracted from https://github.com/nodejs/io.js/labels/tc-agenda prior to meeting.
* @chrisdickinson nomination to TC https://github.com/nodejs/io.js/issues/51
* Move readable-stream to iojs org and make authoritative source for io.js to pull _from_ https://github.com/nodejs/io.js/issues/55
* Deprecate domains https://github.com/nodejs/io.js/issues/66
* Decide how to go forward with caine https://github.com/nodejs/io.js/issues/117
* Is it io.js, IO.js, or something else? https://github.com/nodejs/io.js/issues/118
* Build automation update
* extending options from a prototype
https://github.com/nodejs/io.js/issues/62
* Separate I/O tests from simple, so simple tests can be run in parallel
* Statement / stance from TC on exposing a Promises API https://github.com/nodejs/io.js/issues/11
## Links
* **Google Hangouts Video**: https://www.youtube.com/watch?v=otE4IRMVUMo
* **GitHub Issue**: https://github.com/nodejs/io.js/issues/112
* **Original Minutes Google Doc**: https://www.youtube.com/watch?v=otE4IRMVUMo
## Minutes
### Present
* Rod Vagg (facilitator, build representative)
* Ben Noordhuis (TC)
* Bert Belder (TC)
* Chris Dickinson (nominee to TC)
* Fedor Indutny (TC)
* Trevor Norris (TC)
### @chrisdickinson nomination to TC
https://github.com/nodejs/io.js/issues/51
**Unanimous decision to add Chris to TC**
### Move readable-stream to iojs org and make authoritative source for io.js to pull _from_
https://github.com/nodejs/io.js/issues/55
* Chris expressed concerns on doing this, but a -0 for now, give it a go and see how it works
* Discussed the potential difference with joyent/node
* Trevor discussed concerns about the tight coupling of streams to core
* Rod talked about organisational and community concerns
* No -1’s on moving the source of authoritative code and moving readable-stream into iojs
* Need to experiment with the flow: code, issues, docs, etc.
* **Consensus reached on moving readable-stream to iojs and flipping the authoritative code and doc flow**
* Chris and Rod to work on the process in GitHub
### Deprecate domains
https://github.com/nodejs/io.js/issues/66
* Trevor: domains are horrible but we don’t have a good alternative yet
* Ben: +1 on removal but don’t have a good story on what to tell people to use
* Bert: -1, would rather clean up docs to be honest about how it doesn’t do what it was hoped to
* Trevor: domains inhibit progress because of their invasiveness
* Discussed how to document concerns etc.
* Discussed https://github.com/nodejs/io.js/pull/15 which adjusts the domain.run() API
* Agreed:
- Accept PR #15
- **Document that domains are on the way out: soft deprecation** (no util.deprecate())
### Decide how to go forward with Caine (bot)
https://github.com/nodejs/io.js/issues/117
* Fedor talked about _what_ caine is and _why_ it exists: too many emails from the repo, want to set up a system where relevant people are pulled into particular issues rather than having to subscribe to the repo for all notifications
* Chris: primary concern with having an automated bot is the incoming experience for users (like having a join bot on IRC)
* Discussed notifications / labels / etc.
* Bert discussed using a “new” label for triage--automatically add to incoming issues and remove when the issues have been looked at / dealt with by a contributor.
* Trevor voted to **move the discussion to GitHub**
### Is it io.js, IO.js, or something else?
https://github.com/nodejs/io.js/issues/118
* Ben: lowercase is “objectively superior” (j/k)
* No disagreements, the name is “io.js”
* Ben: binary name suggestion “iojs” with symlink to “node”, lots of discussion in https://github.com/nodejs/io.js/issues/43
* **No disagreements, binary name will be “iojs”**
* Ben: how do we handle it on Windows? .bat file (problems with arg forwarding), small .exe
* Agreed to open a new issue to discuss Windows compat (Ben)
### Build automation update
Rod gave a summary of build project status:
- Containerized build system is being improved by an active team in the https://github.com/nodejs/build-containers repo, on target to enable automatic PR tests and status reports back to GitHub (will likely just be Linux distros for the forseeable future)
- Next step is to enable committers to be able to trigger full builds across the build cluster
- Aiming for more automation for a mid-January release, have concerns about Windows and OSX signing and the need for signing keys and how complex they are.
- Chris Lea is working towards nightly builds for .deb-based systems (RHEL / Fedora based systems could come later but the assumption is that people running those systems are _less_ likely to want nightlies)
- https://github.com/nodejs/io.js/issues/13 is an ARM build failure that still needs attention to have ARM part of the build mix and not constantly fail (see https://jenkins-node-forward.nodesource.com for some ARM failures)
### Extending options from a prototype
https://github.com/nodejs/io.js/issues/62
* Chris is asking for input
* Ben: we’re currently only looking at the object’s own properties, and ignoring properties on the prototype.
* Fedor: in general there’s no reason to explicitly check whether properties are on the object or on the prototype chain.
* Ben: **continue in the issue tracker**
* Bert: be consistent. Slightly agree with fedor.
### Separate I/O tests from simple, so simple tests can be run in parallel
* Fedor: discussed the possibility of moving out net and possibly fs tests so the rest can be parallelized. There may be problems with many of the fs tests because they use fixtures.
* Fedor: **agreed to try it out**
* Bert: preference for the “tests” target to run the current test target
### Statement / stance from TC on exposing a Promises API
https://github.com/nodejs/io.js/issues/11
* Rod: can we come up with some kind of statement from the TC regarding the possibility of adding a Promises API to core, even if it’s vague
* Bert: there’s a convergence of functionality around Promises that are making them more useful in conjunction with other ES6/ES7 features, TC should be _open_ to adding a Promises API in the future
* Trevor: would like to simplify the current API so that it’s easier to extend and add abstractions on the top
* Ben: when simplifying, it would be good to have a target for how the simplification can be used, Promises could be one of those
* Bert: It would be weird for Node to go its own path if the rest of the JS ecosystem were to go that way
* Rod & Bert: suggested a statement along the lines of: **Promises doesn’t make sense right now, so it’s not going to happen in the short-term, but the TC is open to change as things evolve in ES6 and ES7 and practical issues are worked out, TC is open to experimentation, a _callback API is unlikely to ever go away_**
* Ben: a +0
* Trevor: pending practical concerns
* Fedor: a -0
* Chris: +0
### Working with nvm, nvmw and similar installation managers
https://github.com/nodejs/io.js/issues/40
* Ben: suggested a dist.iojs.org for hosting binaries
* Ben: suggested a release.txt
* Rod: **leave it up to the build team to work out the mechanics of releases and release.txt and/or release.json and come back to TC for approval or adjustments prior to formal release** (i.e. no need to bikeshed on this here right now)

91
doc/tsc-meetings/io.js/2014-12-17.md

@ -1,91 +0,0 @@
# io.js TC Meeting 2014-12-17
## Links
* **Google Hangouts Video**: https://www.youtube.com/watch?v=7s-VJLQEWXg
* **GitHub Issue**: https://github.com/nodejs/io.js/issues/163
* **Original Minutes Google Doc**: https://docs.google.com/document/d/1PoqGfxpfTFKv5GcKmhMM2siZpPjT9Ba-ooBi-ZbYNi0
## Agenda
Extracted from https://github.com/nodejs/io.js/labels/tc-agenda prior to meeting.
* Bundle tick processor with iojs #158 https://github.com/nodejs/io.js/issues/158
* Release Cycle Proposal #168 https://github.com/nodejs/io.js/issues/168
* Module search security #176 https://github.com/nodejs/io.js/pull/176
* Dealing with feature requests
## Review of last meeting
* Move readable-stream to io.js and flip authoritative flow of code, docs and issues
* Soft deprecation of domains, accept PR #15 as last feature addition
* Caine, discussion continued on GitHub
* Project name is “io.js”, binary name is “iojs”
* Extending options from prototype, discussion continued on GitHub
* Promises statement for issue #11
* Working with nvm, etc.
## Minutes
### Present
* Bert (TC)
* Chris (TC)
* Trevor (TC)
* Isaac (TC)
* Rod (build, facilitator)
### Bundle tick processor with iojs #158
https://github.com/nodejs/io.js/issues/158
* Bert: important because it’s tied to the version of V8, not practical to put it in npm because one is needed for each version
* Isaac: this is minimal and shouldn’t set a standard for just adding more stuff to core (i.e. keep core minimal), so +1
+1 from Isaac, +1 from Bert, **no disagreement amongst group, consensus has been reached on bundling a tick processor with releases.**
### Release Cycle Proposal #168
https://github.com/nodejs/io.js/issues/168
* Bert & Isaac discussed how this feeds into the ability to have frequent releases. Discussed semver plays into this.
* Rod: consensus seems to be around having stability, predictability, lead-time but more frequent releases.
* **Bert: Move discussion to #168. Still premature to discuss here.**
### Module search security #176
https://github.com/nodejs/io.js/pull/176
* Limiting node_modules search path to $HOME as a top-level
* Isaac ~ -1 on this because EACCES already happens when you don’t have permission
* Isaac and Bert bikeshedded Windows C:\ writability and security on Windows. i.e. if someone can install code on a shared system above where a node application is running (e.g. C:\) then you could have untrusted code run by your application.
* Isaac: this PR is only addressing projects running in the home directory.
* Rod: module system is locked-down, TC needs to come to consensus that this is a _security_ issue and therefore warrants breaking it.
* Chris: `useradd node_modules` is a situation this could be a problem
* Isaac: not convinced this is a security problem, even the `useradd` situation requires root access on a system.
* Bert: this is an academic issue, it may _feel_ wrong but that doesn’t mean it’s strictly a security issue.
* Isaac: proposed the issue be closed as not a security issue.
* **No consensus that this is a security issue. Move discussion back to GitHub, potentially close issue, potentially bringing discussion back here. Encourage users to bring examples of real problems.**
### Dealing with feature requests
* Bert: asking for discussion about what to do with feature requests that come up but aren’t clearly something that are wanted.
* Bert: should we put a time limit on feature requests? Would like some guidelines for how to deal with these.
* Chris: have already been putting a 4-6 day window before closing them. If there is no code then it’s easier to close. If there is code then there could be more discussion.
* Isaac: this is a broader problem about the roadmap-setting process.
* Rod & Isaac: It’s up to someone on TC (or elsewhere) to start coming up with a roadmap, or at least start the discussion.
* **Agreed to start a GitHub discussion on roadmap and soliciting feedback from the community.**
* Rod: in an open model, it’s up to TC and those with commit access to take the initiative to just close things, given enough warning and chance for discussion and better arguments.
* Isaac: builtins (like Blog of FileReader) are TC39 / WhatWG groups out there that are doing this at the language & V8 level and we pull from there. It should be straightforward to close those issues.
* Bert: the roadmap shouldn’t be about locking down the dev process and tightly limiting scope of what’s added.
* **Agreed that feedback to all contributors (including TC), regarding closing issues: close issues that are instinctively bad and worth closing (close can be undone), anything potentially controversial can be flagged with a “will close” but give ~ 1 week for discussion, disagreement, lobbying etc.**
### Logos
* **Agreed that the release is the only _technical_ blocker from the TC’s perspective to a logo, so deferring discussion till then. Encourage interested parties from discussing this further on GitHub issue #37.**
### Next meeting
* Bert proposed 2014-12-30 as next meeting time

95
doc/tsc-meetings/io.js/2014-12-30.md

@ -1,95 +0,0 @@
# io.js TC Meeting 2014-12-30
## Links
* **Google Hangouts Video**: http://www.youtube.com/watch?v=O60sOsesjOo
* **GitHub Issue**: https://github.com/nodejs/io.js/issues/211
* **Original Minutes Google Doc**: https://docs.google.com/document/d/1KLfX2MZQbVSIaD2lBVqOFK0Kap4uFz9cTGihnpTuvPE
## Agenda
Extracted from https://github.com/nodejs/io.js/labels/tc-agenda prior to meeting.
* sys: Remove after 3 years of deprecation #182 https://github.com/nodejs/io.js/pull/182
* module: force require('process') to return a reference to process #206 https://github.com/nodejs/io.js/pull/206
* File copyright policy #216 https://github.com/nodejs/io.js/pull/216
* Rename v0.12 to v1.0.0 https://github.com/nodejs/io.js/issues/218
* Merge strategy (v0.10 and joyent/node)
## Minutes
### Present
* Rod (build, facilitator)
* Ben (TC)
* Bert (TC)
* Chris (TC)
* Fedor (TC)
* Trevor (TC)
### sys: Remove after 3 years of deprecation #182
https://github.com/nodejs/io.js/pull/182
* Ben: what sort of strategy to take? Deprecated only in the docs but no warning. Looking for an official deprecation policy.
* Bert: suggest we could properly deprecate but not a good case for removing it completely, Chris agreed
* Fedor: suggested a policy that removal of deprecated features should be done where there is a maintenance overhead, but otherwise if there is little/no cost then "who cares"
* Discussed a deprecation message on `require(‘sys’)`
* Ben: -0
* Fedor: +1
* Chris: +1
* Trevor: -0
* Bert: +1
* No disagreement to adding a deprecation message, **ask initial PR submitter to change to just adding a message**
### module: force require('process') to return a reference to process #206
https://github.com/nodejs/io.js/pull/206
* #157 has a long discussion on this: https://github.com/nodejs/io.js/issues/157
* Chris: +1 on a PR adding this
* Trevor: it just returns a global, no point
* Bert: not the way that JS adds new features; discussed the new Intl addition to joyent/node, in favor of making more things requirable rather than adding new globals all the time
* Tangential discussion on the Intl object being added in joyent/node
* Collected votes:
* Bert: +0
* Ben: +0.5
* Trevor: -0
* Fedor: +1
* Chris: +1
* **Ben to handle the merge / resolution**
### File copyright policy #216
https://github.com/nodejs/io.js/pull/216
* Rod asked if there are any strong opinions about how to handle this
* **Group agreed that Rod will take this issue and seek legal advice to find a way forward**
### Rename v0.12 to v1.0.0
https://github.com/nodejs/io.js/issues/218
* Trevor: concerns about 1.0 vs 1.x branch naming with maintaining semver releases while also doing LTS, 1.x effectively becomes master until a 2.0 comes along.
* Bert: -1
* Ben: +1
* Chris: +1
* Fedor: +1
* Trevor: 0
Action: **Rename to "v1.x", Ben agreed to make the change**
### Merge strategy (v0.10 and joyent/node)
* _Much_ discussion about merge strategies, patches, branches, etc.
* Agreed to merge regularly
* **Bert agreed to monitor the situation and propose a merge strategy when the time is right**
### Next meeting
* Agreed to meet again on the 7th of January UTC
* Agreed to have mini-stand-up at the beginning of each meeting

154
doc/tsc-meetings/io.js/2015-01-07.md

@ -1,154 +0,0 @@
# io.js TC Meeting 2015-01-07
## Links
* **Google Hangouts Video**: http://www.youtube.com/watch?v=hWDSToC9EV8
* **GitHub Issue**: https://github.com/nodejs/io.js/issues/230
* **Original Minutes Google Doc**: https://docs.google.com/document/d/1j7Sdui5DqHE8GZHxuoAaoIQ4jlntacZI285OCfVa-Eo
## Agenda
Extracted from https://github.com/nodejs/io.js/labels/tc-agenda prior to meeting.
* Invite Colin Ihrig to the TC #223 https://github.com/nodejs/io.js/issues/223
* File copyright policy #216 https://github.com/nodejs/io.js/issues/216
* Doc: clarified & split up contribution docs #233 https://github.com/nodejs/io.js/pull/233
* Governance: Add new Collaborators #234 https://github.com/nodejs/io.js/issues/234
* deps: upgrade v8 to 3.31.74.1 #243 https://github.com/nodejs/io.js/pull/243
* Build
* Intl - defaults
* Merge v0.10
* npm upgrade _(did not get to this)_
## Minutes
### Present
* Bert (TC)
* Ben (TC)
* Chris (TC)
* Fedor (TC)
* Isaac (TC)
* Colin (for voting as addition to TC)
* Mikeal
* Rod (facilitator)
### Mini stand-up
* ben: integrating tick processor, rename binary to “iojs”, upgrade v8, and plenty of libuv features/bug fixes.
* bert: libuv: readdir on windows, build with clang, plan for next unstable libuv, use similar ev loop impl on windows as unix first tentative patches available for review.
* chris: streams - solving failure on v1.x branch for npm, zlib patch breaks stuff, streams visualization stuff doc/writeup of node streams and whatWG streams
* fedor /few-dir/: no updates, working on non-iojs stuff and holidays
* colin: triaging issues in io.js and joyent/node. helping with merge of 0.12 to 0.10
* isaac: no io.js, vacation
* mikeal: nada
* rod: build build build ci ci ci. re-did all the build slaves on Jenkins, introduced a bunch more. Ansible scripts for linux machines (CentOS 5,6,7, Ubuntu all LTS + Current 14.10 +32bit versions, 2 ARM v7s one virtual one physical, 2 of each Windows 2012,2008, a couple interim OS X machines more permanent ones coming from Voxer soon). https://github.com/nodejs/build Still lacking specific Jenkins setup and secrets. Working on release process.
mikeal: issue re release?
rod: not yet, a lot of little bugs to get CI working consistently. No grand plan for what’s in release yet.
### Review of last meeting
* sys: Remove after 3 years of deprecation #182
* module: force require('process') to return a reference to process #206
* File copyright policy #216
* Rename v0.12 to v1.0.0
* Merge strategy (v0.10 and joyent/node)
### Invite Colin Ihrig to the TC #223
https://github.com/nodejs/io.js/issues/223
Asked for vote
Passed unanimously
Some discussion about TC member addition process
### File copyright policy #216
https://github.com/nodejs/io.js/issues/216
* Rod: got feedback from NodeSource GC on this, recommendation is to keep the copyright but removal of the license notice is acceptable
* Mikeal & Isaac: removing the copyright should be OK because we have full git record of who made & edited the file, it’s a PITA
* Asked for vote on removing copyright and license from the top of each source file, moving it a single top level file. **Nobody objected**.
* Agreed to table further discussion on modifying the license and copyright.
* isaacs will submit PR to remove license blocks from files.
### Doc: clarified & split up contribution docs #233
https://github.com/nodejs/io.js/pull/233
* Rod: discussed changes introduced in #233, this is in TC because there are some minor modifications to the governance structure. Recommended that we deal with further changes to governance as a separate discussion.
* Fedor: remove caine block from CONTRIBUTING.md
* Mikeal: take PR as is, move the rest to further discussion & PR
* No objections, agreed to move changes to governance and other adjustments such as moving docs into the docs dir to separate pull requests.
* Isaacs and Chris will review and +1 the PR.
### Governance: Add new Collaborators #234
https://github.com/nodejs/io.js/issues/234
Rod discussed the generation of the list of proposed collaborators.
Long discussion:
* Isaacs, Chris, Bert suggest throttling new contrib additions to 5/week, bump up to 10/week if it goes well, etc.
* Ben 50/50 on “add everyone now” or “throttle new additions”
* Bert to review list and see if there’s any contributors that seem we should not add.
* Other TC members can review list this week.
* Two issues to vote on at next TC meeting
- Issue 1:
a. Add everyone
b. Add everyone except some that are not added
- Issue 2:
a. Create a queue of people to add, throttle per week
b. Add immediately
### deps: upgrade v8 to 3.31.74.1 #243
https://github.com/nodejs/io.js/pull/243
* Ben: clean compile, apparently a clean upgrade. It does break postmortem support so Ben removed it completely. Asked who was using it.
* Ben: adds new features:
- numeric literals
- string methods
- block scoping
- classes (strict mode)
- object literal extensions
- template literals.
* Fedor: Voxer using postmortem support, so it’s not just Joyent. Would prefer to fix it.
* No disagreement about merging this.
* Ben and Fedor to take discussion about details to GitHub.
### Build & release
Rod rambled on about build & release:
* Lots of minor test failures to take care of and make sure there are no serious blockers: https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/
* is osx 32-bit necessary? group agreed to leave it out.
* binary naming: Ben currently taking care of renaming, Bert will help out with a solution for windows
* release blobs:
- source
- windows 32, 64
- osx 64-bit, built on 10.10 - specify minimum requirement in XCode (apparently)
- linux, centos 5, libstdc++ static - Ben says we shouldn't have to, although Rod found it necessary when built with Debian Weezy, give Ben access to CentOS box to try it out
- linux armv7 (built on Ubuntu 14.04) (perhaps armv6 for rpi, but compile should not hold up a release--drop in later?)
- Windows bare files, Bert explained the files currently released in nodejs.org/dist/*/
- node.lib downloaded by node-gyp for compile
- node.pdb contains debug information (may not be needed, not used by the group, perhaps someone asked for it?), leave it out
- node.exe is useful where an .msi is a problem to run (no admin access)
- Rod proposed to move to a .zip for these for 32 and 64, but this may be a problem to get ready for release, discuss further with Bert
* Version number - all agreed to go with 1.0.0, but it should be clearly labeled as an initial “beta”-type release for the project.
* Website for blog/announce/news, Rod proposed Mikeal take responsibility for now until we find a better owner / team, Mikeal agreed.
* Dist folder structure
- Agreed to keep iojs.org/dist/ to mirror nodejs.org/dist, other things via symlinks and html hyperlinks.
- Maybe have a iojs.org/downloads/v1/1.0.0/… and perhaps a text/html thing with links to each relevant release
* Bert: Node still merging in 0.10 to 0.12, is there anything that should be merged in 0.10 that we really need?
* intl: Bert kind of hates this patch. joyent/node is moving towards building with small icu, you get intl object, but only supports english. CAN build with another icu to add other intls. Bert to open an issue to discuss further. May leave out ICU completely from 1.0.0.
### Next meeting
* Bring a day forward to bless a release, i.e. 2015-01-13

101
doc/tsc-meetings/io.js/2015-01-13.md

@ -1,101 +0,0 @@
# io.js TC Meeting 2015-01-13
## Links
* **Google Hangouts Video**: http://www.youtube.com/watch?v=Z0KHYPlFI3E
* **GitHub Issue**: https://github.com/nodejs/io.js/issues/300
* **Original Minutes Google Doc**: https://docs.google.com/document/d/1HDUayYxTjolYZhu_hGm9hc-6MGAwWrHlNGT2Zo708ck
## Agenda
Extracted from https://github.com/nodejs/io.js/labels/tc-agenda prior to meeting.
* File copyright policy #216 https://github.com/nodejs/io.js/issues/216
* governance: Add new Collaborators #234 https://github.com/nodejs/io.js/issues/234
* The state of ES6 on io.js _(re V8 upgrade policy)_ #251 https://github.com/nodejs/io.js/issues/251
Quick recap:
- Whether if it is ok to release 1.0.0 with V8 3.31.74 minus ES6 Classes and Object Literals Extensions, considering that the initial version of io.js will be "beta" quality and probably the stable version will coincide with the stable release of V8 3.31 (~6 weeks), which will have these features reinstated.
- How to handle V8 updates with semver so that if the same issue arised with a different timing it could mean a bump to 2.0.0.
- Community suggestions:
* Different version naming (e.g. 1.x+v8beta, 1.x+v8dev, 1.x+v8canary)
* Avoid BC by moving from tip-of-stable-Chrome-branch to the next tip-of-stable-Chrome-branch (~6 weeks release cycle)
- How do nightly builds fit into the process.
* 1.0.0 release checklist https://github.com/nodejs/io.js/issues/302
## Minutes
### Present
* Trevor (TC)
* Chris (TC)
* Ben (TC)
* Bert (TC)
* Rod (facilitator)
### Mini stand-up
* Ben: 1.0.0 work
* Bert: 1.0.0 work (and other things)
* Chris: Docs mainly, made a new repo for it
* Trevor: Stuff
* Rod: tons of 1.0.0 release prep work, tidying up test slaves, preparing fresh release slaves and configuring release builds & installers
### Review of last meeting
* Invite Colin Ihrig to the TC #223 https://github.com/nodejs/io.js/issues/223
* File copyright policy #216 https://github.com/nodejs/io.js/issues/216
* Doc: clarified & split up contribution docs #233 https://github.com/nodejs/io.js/pull/233
* Governance: Add new Collaborators #234 https://github.com/nodejs/io.js/issues/234
* deps: upgrade v8 to 3.31.74.1 #243 https://github.com/nodejs/io.js/pull/243
* Build & release (& Intl)
### File copyright policy #216
https://github.com/nodejs/io.js/issues/216
Rod: prepared a proposed new LICENSE file, needed for release, adds a new license block for io.js at the top, shifts the Joyent copyright block down but still acknowledges their claim on inherited work. https://github.com/nodejs/io.js/pull/294
Group agreed to merge for now until a better (or more legally appropriate) solution is proposed.
### governance: Add new Collaborators #234
https://github.com/nodejs/io.js/issues/234
Rod asked if we should punt to next meeting since the group was small and we’re 1.0.0 obsessed.
Group agreed.
### The state of ES6 on io.js _(re V8 upgrade policy)_ #251
https://github.com/nodejs/io.js/issues/251
Rod: this is about V8 version matching and V8 version stability. We’re going live with 3.31.
Discussion with the V8 team suggests that 3.31 is probably not appropriate because of stability concerns. We have already had to disable class support because the V8 team announced their intention to disable it in the next release anyway.
Group agreed to stick with 3.31, too late to do otherwise. Come up with a more solid stability policy later.
### v1.0.0 release checklist
https://github.com/nodejs/io.js/issues/302
* Rod will land LICENSE change after meeting
* Bert spoke about the v0.10 and the things that remain unmerged
- abort on uncaughtException for domains not landed, so may be missed; feature used by Hapi / Walmart Labs for postmoretem debugging
- private buffer object patch not landed, repl will crash if you do this currently
- sslv2 & sslv3 fixes -- we have agreed to disable these completely
- re timers slowness - Bert and Ben don’t like the 0.10 fix, need to find our own - not landing in 1.0.0, probably our own fix in 1.0.1
* Bert spoke about node.exe, has code for it but it’s crashy, could release with a symlink for 1.0.0. Asked for input on the approach.
* Discussed node-gyp - Ben to PR node-gyp (and maybe land a modified version in io.js codebase) for iojs.org/dist/vx.y.z/... for source tarball.
- discussed process.versions.iojs property, https://github.com/nodejs/io.js/issues/269 - group agreed to do nothing on this. Rod to find discussion or create issue to have discussion on this.
- discussed visual assets not being in the repo, currently copied by CI manually into src, Rod to land a PR with them
* Rod: Changelog, we don’t have one.
- https://github.com/joyent/node/wiki/API-changes-between-v0.10-and-v0.12
- Rod: is it a blocker? Ben: not per-se but very good to have.
- Rod: proposed to come up with something on GitHub and ask for people to take work. Trevor will do Buffer, Chris streams, Bert child processes.
### Next meeting
* Back to normal schedule next week

166
doc/tsc-meetings/io.js/2015-01-21.md

@ -1,166 +0,0 @@
# io.js TC Meeting 2015-01-21
## Links
* **Google Hangouts Video**: http://www.youtube.com/watch?v=OUoWlIshY9s
* **GitHub Issue**: https://github.com/nodejs/io.js/issues/509
* **Original Minutes Google Doc**: https://docs.google.com//document/d/1yOS17cUt7QUHJXxdVmEpS1ZS_N32HMO9QTHb2qL-KHk
## Agenda
Extracted from https://github.com/nodejs/io.js/labels/tc-agenda prior to meeting.
* Invite Domenic Denicola to the TC Meetings (https://github.com/nodejs/io.js/issues/403)
* Governance: Add new collaborators (https://github.com/nodejs/io.js/issues/234)
* Stabilization and Release Cycles and Process (https://github.com/nodejs/io.js/issues/405)
* also: the state of ES6 on io.js (re: V8 upgrade policy) (https://github.com/nodejs/io.js/issues/251)
* doc: bump punycode api stability to ‘stable’ (https://github.com/nodejs/io.js/issues/470)
* Working group reports
* Streams
* Website
* ICU
## Minutes
### Present
* Bert (TC)
* Ben (TC)
* Chris (TC)
* Colin (TC)
* Fedor (TC)
* Isaac (TC)
* Mikeal
* Rod
* Domenic
### Mini stand-up
* Bert: Release, polish, Windows installer, Windows XP, ICU
* Ben: Fixing bugs, reviewing PRs, maintenance
* Chris: Cleaning up points where core reaches in to private state of streams, TLS bug with New Relic
* Colin: Reviewing PRs, moving vars to ES6 consts
* Fedor: Commenting, working on replacement for GYP, written in C: https://github.com/indutny/pyg
* Isaac: npm stuff, some streams discussing
* Mikeal: Website WG, social media accounts, facebook, G+, etc.
* Domenic: Changelog & Release, clarifying V8 stuff
* Rod: Release, etc.
### Review of last meeting
* File copyright policy #216
- LICENSE file
* governance: Add new Collaborators #234
- Deferred to this meeting
* The state of ES6 on io.js _(re V8 upgrade policy)_ #251
- Only discussed V8 upgrade policy, re 3.31 vs 3.30
* 1.0.0 release checklist
### Invite Domenic Denicola to the TC Meetings
(https://github.com/nodejs/io.js/issues/403)
Enough agreement on GitHub and in private communications amongst TC. **Done.**
### Governance: Add new collaborators
(https://github.com/nodejs/io.js/issues/234)
* Mikeal: Proposed Chris leads an onboarding process, do a Hangout with a group of people from the original list who are willing to go through the process and take them in the first week and iterate from there.
* Bert: +1 for an onboarding process, more interested in handing out voting rights to a larger group.
* Mikeal: Would rather separate the voting rights issue from adding contributors, make a separate issue for this with ideas and come back to it at next meeting.
* Ben: is an onboarding process necessary? New contributor should pick it up fairly quickly.
* Chris: How we review code and deal with issues (cultural things) is hard to get across with just a written process.
* Isaac: Basically apprentice model for joyent/node but faster and more inclusive. Some brief instruction on how to do things.
* Mikeal: adding collaborators gives us an informal voting process, +/-1s on issues with the “collaborator” badge
* Bert: would like to widen and formalise the voting process
* Mikeal: wants to tackle the issue by bringing org to the roadmap repo, will bring Bert in on the process
Discussed whether onboarding should be mandatory.
Proposal: **take anyone proposed that +1s in that thread, mandatory onboarding process by Chris, limited by how many he can take.**
Passed
### Stabilization and Release Cycles and Process
(https://github.com/nodejs/io.js/issues/405)
#### V8
* Mikeal:
- how to align with V8 process and increase collaboration
- semver + V8 introduces some challenges
* Domenic: V8 is synced to Chrome releases, Beta should ship with the version that ships with release
* Ben: is the proposal to stick with stable V8 release that’s in stable Chrome?
* Domenic: ideally some “beta” version of io.js that uses a Beta V8
* Mikeal: we need more releases to get experience with this, assumption is that at some point we say “this is stable” and have a stable and unstable branch.
* Discussed current release patterns, how they map to minor/patch
* Domenic: we are in a “danger zone”
* Mikeal & Domenic discussed how you might achieve a “canary”
* Bert: proposal:
- io.js track stable V8, bump minor and possibly major as required
- have a pre-release that tracks the Beta
* Domenic: would like to keep V8 version upgrades as a separate concern to other experimental additions to io.js, decouple from io.js releases / semver?
* Ben: happy with stable proposal, want to move discussion on unstable to an issue for further discussion.
* Action: **Ben file an issue to discuss how unstable works**
* **Agreement: V8 should track stable**
#### Logo
* Discussed logo-per-release
* Mikeal: we need a versatile logo to use across all web / social presences. Having a logo to designate a release would be good.
* Mikeal: ideally website team would like JSON file containing release info to be checked in to the website repo upon completion.
#### Releases
* Rod: patch releases should be frequent, there have been 4 so far, it seems to be working well but we should monitor
* Domenic: frequent releases should be normal, patch & minor should just be part of the normal process
* Bert: would be good to have API change notes into the git log
* Discussed further about how to deal with API changes minor/major, unstable branches, etc.
* **Agreement: patch and minor releases are merged as part of normal business, a release then is either a patch or minor bump depending on what was merged.**
* Move discussion about tagging vs git log recording for patch/minor/major to GitHub.
* **Punt on discussions about who can release and how that happens**
* **Punt on discussions about synchronizing with important ecosystem projects (NAN, node-gyp, nvm, etc.)**
### also: the state of ES6 on io.js (re: V8 upgrade policy)
(https://github.com/nodejs/io.js/issues/251)
Part of previous discussion
### doc: bump punycode api stability to ‘stable’
(https://github.com/nodejs/io.js/issues/470)
* **Agreement**
### Working group reports
* Mikeal and Chris to semi-formalise the model
* Mikeal: 6 people actively engaged and growing, “could not be going better”
* Chris: streams group has initial set of members, some discussions going on, first meeting pending
* initial set of members: https://github.com/nodejs/readable-stream/issues/97#issuecomment-70399923
* Rod:
- The Docker sub-group is going great and has even got the docker-iojs images accepted as the official Docker "iojs" images.
- Other "build" efforts are all release-focused for now, trying to streamline the process to make it possible to have multiple people able to cut releases.
### ICU
* Bert:
- joyent/node has small-icu enabled by default making `Intl` work
- can get it working but it makes the binary twice as big (~8M more)
* Domenic: ideally we would track browsers and just include it
* Ben: V8 adds ICU by default but you need to opt-out, which we do
* Action: **Invite Steven Loomis to the next TC meeting to discuss further**
### Next meeting
* 28th January 2015

179
doc/tsc-meetings/io.js/2015-01-28.md

@ -1,179 +0,0 @@
# io.js TC Meeting 2015-01-28
## Links
* **Google Hangouts Video**: http://www.youtube.com/watch?v=k27NObxy0ps
* **GitHub Issue**: https://github.com/nodejs/io.js/issues/565
* **Original Minutes Google Doc**: https://docs.google.com/document/d/1IIfubVivCORgP0nQfo8Mf4gXhwBrndRm9cwmNGBXmtE
## Agenda
Extracted from https://github.com/nodejs/io.js/labels/tc-agenda prior to meeting.
* governance: Add new Collaborators [#234](https://github.com/nodejs/io.js/issues/234) / feedback and more contribs / @chrisdickinson
* Stabilization and Release Cycles and Process [#405](https://github.com/nodejs/io.js/issues/405) / further discussion / @iojs/tc
- doc: add releases document detail release cycle [#630](https://github.com/nodejs/io.js/issues/630) / proposal from @chrisdickinson
* dgram: implicit binds should be exclusive [#325](https://github.com/nodejs/io.js/issues/325) / minor version bump / @bnoordhuis
* buffer: implement `iterable` interface [#525](https://github.com/nodejs/io.js/issues/525) / minor version bump / @bnoordhuis
* replace util.isType() with typeof [#607](https://github.com/nodejs/io.js/issues/607) / general use of util.is*() in core re perf
* docs: lower the maximum stability level to "stable" [#633](https://github.com/nodejs/io.js/pull/633)
* maintain our own package registries for io.js related packages [#640](https://github.com/nodejs/io.js/issues/640#issuecomment-71882645)
* Working Groups PR [#599](https://github.com/nodejs/io.js/pull/599)
* Remove “unstable” from messaging [#108](https://github.com/nodejs/website/issues/108)
## Minutes
### Present
* Ben (TC)
* Bert (TC)
* Chris (TC)
* Colin (TC)
* Fedor (TC)
* Isaac (TC)
* Mikeal
* Rod
Apologies from:
* Trevor (TC)
* Domenic
### Mini stand-up
* Ben: Reviewed/landed pull requests, fixed bugs, the usual
* Bert: Same as Ben, but not as much
* Chris: On-boarding stuff
* Colin:
* Fedor: working on pyg (gyp alternative in C)
* Rod: ARMv6 builds, fixing persistent bug on Ubuntu 10.04, yay!
* Isaacs: Only doing npm CEO stuff
* Mikeal: social media stuff for io.js, PR, roadmap, feedback from Big Cos.
### Review of last meeting
* Invite Domenic Denicola to the TC Meetings (https://github.com/nodejs/io.js/issues/403)
* Governance: Add new collaborators (https://github.com/nodejs/io.js/issues/234)
* Stabilization and Release Cycles and Process (https://github.com/nodejs/io.js/issues/405)
* also: the state of ES6 on io.js (re: V8 upgrade policy) (https://github.com/nodejs/io.js/issues/251)
* doc: bump punycode api stability to ‘stable’ (https://github.com/nodejs/io.js/issues/470)
* Working group reports
* Streams
* Website
* ICU
### governance: Add new Collaborators
[#234](https://github.com/nodejs/io.js/issues/234) / feedback and more contribs / @chrisdickinson
* Chris: Onboarded 2 groups of 4 new collaborators last week. (first group: @vkurchatkin, @micnic, @seishun, @brendanashworth, second group: @evanlucas, @Fishrock123, @Qard, @thlorenz)
- 30 min summary of how everything works, gov, git, etc.
- took exit poll to get reactions
- notes here: https://gist.github.com/chrisdickinson/80df88b9089c19e0459e
* Rod: how do we iterate?
* Chris: Do it again next week with ~4 more
* Discussed timezones and how that works
### Stabilization and Release Cycles and Process
[#405](https://github.com/nodejs/io.js/issues/405) / further discussion / @iojs/tc
***Also:*** doc: add releases document detail release cycle [#630](https://github.com/nodejs/io.js/issues/630) / proposal from @chrisdickinson
Moved straight to Chris’ proposal:
* Chris discussed thoughts in his proposal @ https://github.com/nodejs/io.js/issues/630
* Mikeal: would rather not have a static number/list of supported versions, let that be dynamic as people & companies step up to help support them
* Ben: “stable” and “next” would be easiest to reason about
* Chris: “dev” is for ad-hoc semver releases, replaces nightlies with a better train system.
* Chris: branches will be “master” - development happens here, maintain “v1.x”, “v2.x” etc. for major releases. Ideally LTS would be from major versions.
* Fedor asked about communication to users and how much fragmentation this would cause
* Ben: how do you keep the delta between dev and stable from getting too big
* Chris: at most there would be a 2-week lag between something hitting dev and something going out on stable
* Bert: suggested that we need a better batching mechanism, particularly for breaking changes, so we’re not constantly bumping major.
### dgram: implicit binds should be exclusive
[#325](https://github.com/nodejs/io.js/issues/325) / minor version bump / @bnoordhuis
* Ben: this is about minor version bump, that’s been decided and we’re doing a 1.1.0 so this is being merged and released
### buffer: implement `iterable` interface
[#525](https://github.com/nodejs/io.js/issues/525) / minor version bump / @bnoordhuis
* Ben: same as previous issue, resolved
### replace util.isType() with typeof
[#607](https://github.com/nodejs/io.js/issues/607) / general use of util.is*() in core re perf
* Bert: find with direct comparisons and checks where it makes sense (undefined, simple stuff)
* Isaac: hate it all, they are difficult to inline so manually inline--pick one and use it across all
* Colin: working on a PR to do the replacement already
* Chris volunteered to PR a style-guide into docs
* Isaac: better linter would be great
### Doc-tool - Should we merge with the joyent/node version?
* Isaac: Robert Kowalski reached out to me to ask about this.
- Seems silly to have two nearly-identical tools for this.
- Delegate to doc working group?
- Suggested that he just pick one from io.js or joyent/node and send a PR for that
* Mikeal: Website WG is meeting next week, will pull in Robert to that discussion
### docs: lower the maximum stability level to "stable"
[#633](https://github.com/nodejs/io.js/issues/633)
* General disagreement about this
* Mikeal suggested moving things that are likely to change into vendored packages (like streams)
* Motivation was to set some things (frozen/locked) as unchangable because they would break too much stuff
* Bert: we effectively have 4 levels: strict-deprecation, soft-deprecation, moving, pretty-much-done
* Mikeal: proposed punting this for a few weeks
* Isaac: the labels are useful for guiding people on where best to contribute and where to not bother
### maintain our own package registries for io.js related packages
[#640](https://github.com/nodejs/io.js/issues/640)
* Mikeal: each distro (Homebrew, Debian, etc.) has their own conception of “stable”, suggestion is to maintain them under io.js and instruct people how to do this. e.g. using our own custom Homebrew end-point and instruct people how to use it with `brew`. Also could bring in complicated packages from the community.
* Mikeal: Should come under the Build WG for now, ideally a single repo where external projects can put in a single PR to update their stuff.
### Working Groups PR
[#599](https://github.com/nodejs/io.js/issues/599)
* Mikeal introduced his proposal: if you’re going to do the work in a WG then you can spin that up as a separate concern
* Ben asked for clarification about whether WGs get a free-pass in core
- Mikeal: no, they are isolated from core
* Rod: clarification about relationship to TC
- TC has charter-revocation powers, beyond that they don’t have control over the activities of a WG
* Consensus reached, Mikeal will put in the suggested fixes (in the PR) into the docs and merge
### Remove “unstable” from messaging
[#108](https://github.com/nodejs/io.js/issues/108)
* Remove “unstable” from the website but not say it’s “stable”
* Bert: big +1, use semver, don’t try and message something else, only concern is the version of V8 we are using
* Discussed V8 4.1 and how “stable” it is
### Node.js and io.js should not break each other (no, they shouldn't)
[#631](https://github.com/nodejs/io.js/issues/631)
Rod brought this up for quick discussion and draw attention to TC members for possible input.
* Mikeal suggested that this should be taken to the website WG for better documentation
### Working group reports
* Streams
- first WG meeting this week
* Website
- meeting next week
### Next meeting
* 4th of February

107
doc/tsc-meetings/io.js/2015-02-04.md

@ -1,107 +0,0 @@
# io.js TC Meeting 2015-02-04
## Links
* **Google Hangouts Video**: http://www.youtube.com/watch?v=k27NObxy0ps
* **GitHub Issue**: https://github.com/nodejs/io.js/issues/509
* **Original Minutes Google Doc**: https://docs.google.com/document/d/1IIfubVivCORgP0nQfo8Mf4gXhwBrndRm9cwmNGBXmtE
## Agenda
Extracted from https://github.com/nodejs/io.js/labels/tc-agenda prior to meeting.
* assert: don't compare object `prototype` property [#636](https://github.com/nodejs/io.js/pull/636) _and_ assert: introduce `deepStrictEqual` [#639](https://github.com/nodejs/io.js/pull/639) / @vkurchatkin
* Release PGP key strategy and policy [#709](https://github.com/nodejs/io.js/issues/709)
* If time: vm bugs? [#548](https://github.com/nodejs/io.js/issues/548), [joyent/node#9084](https://github.com/joyent/node/issues/9084)
## Minutes
### Present
* Ben (TC)
* Bert (TC)
* Chris (TC)
* Colin (TC)
* Fedor (TC)
* Isaac (TC)
* Trevor (TC)
* Mikeal
* Domenic
* Rod
### Mini stand-up
* Bert: Lots of commenting, still working on ICU, investigating binary size and memory size minimisation, playing with transforming the data to C
* Chris: Integrating ESLint, held first Streams WG meeting
* Colin: Issues and codez, removed all util.is type functions
* Isaac: “Real job” stuff
* Domenic: Streams WG
* Mikeal: Starting Tracing WG, lots of org stuff, roadmap work, early feedback from reaching out to companies is that there is concern about version number conflict between io.js and Node, and debugging/tracing.
* Trevor: moving house, tracing
* Rod: build collaboration stuff
### Review of last meeting
* governance: Add new Collaborators [#234](https://github.com/nodejs/io.js/issues/234) / feedback and more contribs / @chrisdickinson
* Stabilization and Release Cycles and Process [#405](https://github.com/nodejs/io.js/issues/405) / further discussion / @iojs/tc
- doc: add releases document detail release cycle [#630](https://github.com/nodejs/io.js/issues/630) / proposal from @chrisdickinson
* dgram: implicit binds should be exclusive [#325](https://github.com/nodejs/io.js/issues/325) / minor version bump / @bnoordhuis
* buffer: implement `iterable` interface [#525](https://github.com/nodejs/io.js/issues/525) / minor version bump / @bnoordhuis
* replace util.isType() with typeof [#607](https://github.com/nodejs/io.js/issues/607) / general use of util.is*() in core re perf
* docs: lower the maximum stability level to "stable" (https://github.com/nodejs/io.js/pull/633)
* maintain our own package registries for io.js related packages (https://github.com/nodejs/io.js/issues/640#issuecomment-71882645)
* Working Groups PR (https://github.com/nodejs/io.js/pull/599)
* Remove “unstable” from messaging (https://github.com/nodejs/website/issues/108)
* Node.js and io.js should not break each other (no, they shouldn't)
* Working group reports
### assert: don't compare object `prototype` property _and_ assert: introduce `deepStrictEqual` / @vkurchatkin
@vkurchatkin questions:
* the future of assert module;
* relationship between assert and CommonJS Unit Testing spec;
* particular #636 bug;
* what "deep equality" means and how it should deal with prototypes;
* [#639](https://github.com/nodejs/io.js/pull/639) proposal
* Isaac: CommonJS is gone & dead, good ideas have to stand on their own
* Mikeal: assert probably shouldn’t be in core
* Isaac: it’s useful for testing Node itself and useful for runtime asserts
* Rod asked if anyone had any objections to the changes because perhaps Validmir should just be given a blessing to go ahead and improve it.
* Domenic: medium risk, low reward, perhaps slate this for a 2.0 release.
* Lots of discussion about the technical merits
* Ben: the `a.prototype !== b.prototype` is clearly a bug in the initial implementation, it should have been checking `__proto__`
* Rod: new deepStrictEqual() does that check properly
Conclusion: accept both of
- [#636](https://github.com/nodejs/io.js/pull/636)
- [#639](https://github.com/nodejs/io.js/pull/639)
(Contrast #636 with [#621](https://github.com/nodejs/io.js/pull/621), which is a more ambitious change and probably not a good idea.)
1. deepEqual = No prototype checking
2. deepStrictEqual = proper prototype checking
Passed without objection
### Release PGP key strategy and policy / @rvagg
[#709](https://github.com/nodejs/io.js/issues/709)
* Rod summarised how the current release key strategy works and is documented on the README. Asked for feedback on:
- Which keyserver(s) to use
- Whether to go with a master/sub key design for the project
* No strong opinions, nothing actionable here
### VM bugs? [#548](https://github.com/nodejs/io.js/issues/548) / @domenic
[joyent/node#9084](https://github.com/joyent/node/issues/9084)
* Domenic introduced #548, some odd VM bugs that seem to be V8 bugs,
* Isaac encouraged Domenic to follow this up with the V8 team to get feedback on how this works
### Next meeting
* Skipping a week due to Node Summit
* Feb 18th 2015

129
doc/tsc-meetings/io.js/2015-02-18.md

@ -1,129 +0,0 @@
# io.js TC Meeting 2015-02-18
## Links
* **Public YouTube feed**: http://www.youtube.com/watch?v=jeBPYLJ2_Yc
* **Google Plus Event page**: https://plus.google.com/events/ccrkam8uup1k8qbo0fmcea0n2v4
* **GitHub Issue**: https://github.com/nodejs/io.js/issues/509
* **Original Minutes Google Doc**: https://docs.google.com/document/d/1JnujRu6Rfnp6wvbvwCfxXnsjLySunQ_yah91pkvSFdQ
## Agenda
Extracted from https://github.com/nodejs/io.js/labels/tc-agenda prior to meeting.
* util: fixed behavior of isObject() [#822](https://github.com/nodejs/io.js/issues/822) / @chrisdickinson / major version release
* Translate installers for OS X and Windows [#819](https://github.com/nodejs/io.js/issues/819) / @rvagg / maintenance overhead
* lib: fix process.send() sync i/o regression [#774](https://github.com/nodejs/io.js/issues/774) / @bnoordhuis
* Implement unhandled rejection tracking [#758](https://github.com/nodejs/io.js/issues/758) / @rvagg / how can we help this land
* Logo / Brand Treatment
[website/181](https://github.com/nodejs/website/issues/181) @ mikeal
https://www.behance.net/gallery/23269525/IOJS-logo-concept
* Stability Policy/Statement & Roadmap
[#725](https://github.com/nodejs/io.js/issues/725) / @mikeal
[roadmap/14](https://github.com/nodejs/roadmap/issues/14) / @mikeal
## Minutes
### Present
* Bert (TC)
* Chris (TC)
* Colin (TC)
* Isaac (TC)
* Trevor (TC)
* Mikeal
* Domenic
* Rod
* Apologies for Ben and Fedor
### Mini stand-up
* Bert: NodeSummit and company stuff, Windows io.js stuff
* Chris: styleguide work, wrangling ESLint, slow week
* Colin: busy with work, porting joyent/node work to io.js
* Domenic: having fun with VM stuff in jsdom, have a release coming soon
* Rod: not as much as usual, preparing for 1.3.0
* Isaac: Node Summit, npm stuff
* Mikeal: i18 groups, >160 new people doing translations, press inquiries because of Node Foundation news, lots of website stuff (i18n & build), roadmap and stability
* Trevor: Some critical stuff on joyent/node, work, moving house
### Review of last meeting
* assert: don't compare object `prototype` property _and_ assert: introduce `deepStrictEqual` / @vkurchatkin
* Release PGP key strategy and policy / @rvagg
* VM bugs? [#548](https://github.com/nodejs/io.js/issues/548) / @domenic
### util: fixed behavior of isObject() [#822](https://github.com/nodejs/io.js/issues/822) / @chrisdickinson / major version release
* Chris: Requires semver-major, what’s the vibe on bumping major at this stage?
* Chris: isObject() would now return true when checking for functions
* Mikeal: interested in separating “things that break” and “API breakage”
* Chris: consider this a “fix” but is also an API change that could break people’s downstream code
* Isaac: probably want to put off a 2.x release until we have more substantial changes, not to wait for 2 years but have some time frame, like 6 months
* Bert: messaging is off for a 2.0 bump just for this
* Domenic: versions shouldn’t mean the same as they used to, major version bumps should be more casual
* Rod: are we stopping saying that this is compatible with “Node”?
* Mikeal: compatible with past-Node, not joyent/node 0.12+ because we have no control over that
* Mikeal: release channels - standard semver & canary which is everything else
* Chris: +1 for release channels, but not so much on substance of the proposal.
* Rod: concerned about the emotional energy we’re still investing in version numbers when we should be just doing semver
* Mikeal: ignore version numbers, have a “canary” type branch and start releasing on that until we’re confident to merge back in
* Chris: difference between Mikeal’s proposal and the original proposal is having a “canary” branch that stuff gets merged in to and eventually is merged in to master, original proposal merged new stuff in to master and used the time delay as “canary” (like Chrome)
* Rod: proposal is to tag this issue as a milestone for now and punt until we have more substantive changes - no disagreements, passed
### Translate installers for OS X and Windows [#819](https://github.com/nodejs/io.js/issues/819) / @rvagg / maintenance overhead
* Rod: concern here is the maintenance overhead in keeping all of the translations in sync, are we happy to have that headache in core?
* Mikeal: let English be the default and let the translation teams be responsible for watching for changes and making updates as appropriate
* Bert: installer framework is largely out of our control for how the mechanics of translations and fallbacks work, -1 on this because it’s just an installer and there are probably better targets for translation
* Mikeal: the translation teams will prioritise for themselves what gets translated.
* Domenic: enable the community as long as it doesn’t add friction
* Bert: if there is no technical issue then OK with landing this, the responsibility for translation will have to be with that community
* Resolution: allow this to land unless there are going to be technical blockers to future installer changes needing to wait for translations to be updated
### lib: fix process.send() sync i/o regression [#774](https://github.com/nodejs/io.js/issues/774) / @bnoordhuis
* Ben’s issue, punt till next meeting, note in “known issues” for releases
### Implement unhandled rejection tracking [#758](https://github.com/nodejs/io.js/issues/758) / @rvagg / how can we help this land
* Rod: Brought to TC to get some more engagement and help get this landed unless there are any major objections
* Domenic: PR looks good, it’s mainly a matter of code quality, doesn’t add any default handlers which is a good incremental way of adding this
* Trevor discussed concerns about how V8 runs the events, synchronously vs on the micro-task queue
* Trevor: OK with the change because there is almost no overhead if you’re not using Promises or this event, concerned about the disconnect between the V8 API vs what we expect it to be--the PR compensates for V8 behavior.
* Domenic: user-exposed semantics of this PR are good
* Mikeal: concerned about behavior change in the future leading to a
* Rod: proposed resolution is to give the TC’s blessing to that PR for it to land when everyone in there is happy with it
- No objections
### Logo / Brand Treatment
[website/181](https://github.com/nodejs/website/issues/181) @ mikeal
https://www.behance.net/gallery/23269525/IOJS-logo-concept
* Mikeal discussed the proposed website changes and logo choice @ https://www.behance.net/gallery/23269525/IOJS-logo-concept
* Some discussion about choice of logo, no strong opinions on design
* Rod: may be best to let the website group make this choice because they are more qualified from a design perspective
* Chris: design group could be asked to come up with a few options and present them for selection
* Mikeal: design by committee sucks, everyone knows this
* Chris: can we come up with some standards and assert them ack to designers - such as number of colors, needs to look good at 16x16 all the way up
* Rod: maybe this group isn’t qualified to even do that, perhaps push it on to the WG
* Discussion on the process of selecting a logo and brand treatment
* Agreed to delegate to the website WG to make this decision
### Stability Policy/Statement & Roadmap
[#725](https://github.com/nodejs/io.js/issues/725) / @mikeal
[roadmap/14](https://github.com/nodejs/roadmap/issues/14) / @mikeal
* Mikeal: none of this is fixed in stone, we can change it in the future if we decide it won’t work
- one change still to go in is that the wording on stability should be that “we won’t remove an API”
- people are terrified that we’re going to break compatibility and go off in new directions, this is a way of dealing with that
* Bert: concerned about this being a reflection of the way we work rather than enforcing new behaviors
* Discussion around breaking / removing APIs and how firm this policy is going forward
* Rod asked for specific things that need to be resolved now vs punting to a later meeting
* Mikeal: https://github.com/nodejs/roadmap/commit/190690a1b5f206c22f64adc3d29d10c4b08cb8cd
* Group discussed presentations, no major objections so the blessing was given for Mikeal to move forward with ratifying that, expect further discussion on the broader topic next meeting.
### Next meeting
* Next week, 25th Feb 2015

164
doc/tsc-meetings/io.js/2015-03-04.md

@ -1,164 +0,0 @@
# io.js TC Meeting 2015-03-04
## Links
* **Public YouTube feed**: http://www.youtube.com/watch?v=vxX2CkFPEtk
* **Google Plus Event page**: https://plus.google.com/events/c9ijr7edl14im7dspk5njktmjq4
* **GitHub Issue**: https://github.com/nodejs/io.js/issues/1053
* **Original Minutes Google Doc**: https://docs.google.com/document/d/1RoIE68l8B2iWLdEPM7ApSN2FxFDd3OY0wfTeqUh-K9w
## Agenda
Extracted from https://github.com/nodejs/io.js/labels/tc-agenda prior to meeting.
* lib: fix process.send() sync i/o regression [#774](https://github.com/nodejs/io.js/issues/774) / @bnoordhuis
* iojs: introduce internal modules [#848](https://github.com/nodejs/io.js/issues/848) / @chrisdickinson / @trevnorris / (@vkurchatkin)
* url: significantly improve the performance of the url module [#933](https://github.com/nodejs/io.js/issues/933) / @mikeal
* Ship websockets in core [#1010](https://github.com/nodejs/io.js/issues/1010) / @piscisaureus
* RFC: upgrade to V8 4.2? [#1026](https://github.com/nodejs/io.js/issues/1026) / @bnoordhuis
* Colin resigning from TC [#1056](https://github.com/nodejs/io.js/pull/1056)
## Minutes
### Present
* Ben (TC)
* Bert (TC)
* Chris (TC)
* Domenic
* Fedor (TC)
* Mikeal (meeting lead)
* Isaac (TC)
* Trevor (TC)
* Rod
### Mini stand-up
* Ben: PRs, bugs, perf improvements, same old awesome Ben
* Bert: talking, child process bugs, looking further in to Windows bugs that are still outstanding, no coding
* Chris: reviewing PRs, onboarding Julian, Christian, Brian, Robert, Ben. Code for core module discovery / use in packages in npm.
* Domenic: Streams work WHATWG sync with io.js streams ideas.
* Fedor: fixing bugs, PRs
* Isaac: coding for fun, node-tap rewrite, global/window alias discussions, node_modules flattening, Windows stuff. Looking in to TLS issues for io.js and 0.12, TLS over Pound causes problems, possibly OpenSSL problem.
* Mikeal: Website and Evangelism WG work, lots of new collabs and work, getting things in sync
* Rod: Releases, Windows bug / Jenkins drama, ARMv8 support
* Trevor: Buffer.indexOf(), nextTick perf improvement
### Review of last meeting
* util: fixed behavior of isObject() [#822](https://github.com/nodejs/io.js/issues/822) / @chrisdickinson / major version release
* Translate installers for OS X and Windows [#819](https://github.com/nodejs/io.js/issues/819) / @rvagg / maintenance overhead
* lib: fix process.send() sync i/o regression [#774](https://github.com/nodejs/io.js/issues/774) / @bnoordhuis
* Implement unhandled rejection tracking [#758](https://github.com/nodejs/io.js/issues/758) / @rvagg / how can we help this land
* Logo / Brand Treatment
[website/181] https://github.com/nodejs/website/issues/181 @ mikeal
https://www.behance.net/gallery/23269525/IOJS-logo-concept
* Stability Policy/Statement & Roadmap
[#725](https://github.com/nodejs/io.js/issues/725) / @mikeal
[roadmap/14](https://github.com/nodejs/roadmap/issues/14) / @mikeal
### Colin resigning from TC [#1056](https://github.com/nodejs/io.js/pull/1056)
### lib: fix process.send() sync i/o regression
[#774](https://github.com/nodejs/io.js/issues/774) / @bnoordhuis
* Ben: @orangemocha did some work on Windows for libuv, unsure if this helps.
* Bert: process.send() has been made sync on *nix because otherwise it’s a breaking change, but on Windows it’s always been async so changing it to sync would also be a breaking change. So the situation is crazy.
* Isaac: ideal is that they behave the same and behave well
* Discussion about whether this would be a breaking change or a bugfix
* Bikeshed, moving to GitHub
* Bert: proposed that we revert Unix behaviour and leave Windows as it is
* Ben: current fix adds blocking on Windows
### iojs: introduce internal modules
[#848](https://github.com/nodejs/io.js/issues/848) / @chrisdickinson / @trevnorris / (@vkurchatkin)
Chris: lets us have modules that can’t be required from outside of core. I’m in favor; it’s a nice insurance policy, especially in light of the stability policy that we will try not to make any breaking changes to the JavaScript API.
Mikeal: this doesn’t change the existing pseudo-internal modules to become truly internal, right?
Chris: correct, that is separate.
Domenic: but, doing that operation would be a good thing to do in a major version bump.
Isaac/Mikeal: yes, but don’t do that for `util._extend`, too many people use it.
Chris: *gives example of how this would have been helpful for a recent refactor*
Ben: how will the test suite test internal functions from then on?
Chris: there would be a flag, e.g. --allow_internal_modules.
Mikeal: I like it.
Bert: I like it too. However I am concerned about products that do monkeypatching; would that still be possible?
Chris: I think so, as long as they monkeypatch the public APIs…
Ben: not sure that’s quite sufficient…
Domenic: seems like a pure win because it allows you not to have to put everything in one file to keep things private.
### url: significantly improve the performance of the url module
[#933](https://github.com/nodejs/io.js/issues/933) / @mikeal
This will get rolled in to the major version issue Chris is putting together.
### Ship websockets in core
[#1010](https://github.com/nodejs/io.js/issues/1010) / @piscisaureus
Bert: I’m not sure I believe in this any more; the major reason I wanted this was that building native addons is terrible, but people brought up that the native part of the web socket implementations only do some bitwise buffer stuff and so we could probably just add *those* to core.
Discussion of how we should probably just add more Buffer methods to core.
Bert: there’s another aspect of this. At some point Node was really modern, but we’ve fallen behind. We can’t even get HTTP/2 or web sockets, we’re in trouble.
Domenic: we’ve learned a lot over the last few years that pushes us to userland code instead of in core. But we need to have some things be “official.”
Trevor: I would like the infrastructure for HTTP/2 to be similar to HTTP/1, with http-parser etc.
Ben: is there any reason HTTP/2 couldn’t be done in pure JS?
Discussion of http-parser and current HTTP/1 implementation strategy and speed.
Bert: I think as a TC what we should say is “we would like to support HTTP/2, but want to see some userland ideas first.” We don’t need to actually start implementation progress right now.
Ben: does anyone on the TC want to write a userland HTTP/2 module?
Discussion of how Fedor already has a SPDY implementation.
Trevor: are we going to do TLS-only HTTP/2?
Mikeal: we probably don't want to, because our HTTPS is not as fast as terminators.
Conclusion:
We should start an issue in NG about the core modules/modernity stuff.
We should publicly state that we’re interested in supporting HTTP/2 in the related issue thread, although we’re not sure about implementation strategy and want to see experiments.
### RFC: upgrade to V8 4.2?
[#1026](https://github.com/nodejs/io.js/issues/1026) / @bnoordhuis
* Ben: V8 4.1 has gone gold/stable so we should probably upgrade by un-floating a revert we placed on top of it. I propose we revert that revert, so that we get 4.1-as-shipped-in-Chrome. [#952](https://github.com/nodejs/io.js/pull/952) for details on the floating revert.
* Domenic: do we have clarity about ABI vs. API implications for io.js major version?
* Ben: ABI change means everyone has to recompile their add-ons so we should bump the minor.
* Fedor: this feels more like a major version?
* Domenic: do we consider forcing people to run “npm rebuild” a breaking change?
* Chris: I think I agree that users should not expect to have to rebuild within the same major version.
* Mikeal: how often does a V8 ABI change happen *after that V8 gets into stable Chrome*?
* Domenic: not sure, but would suspect not often at all. Maybe we should check with V8.
* Ben: yes, not often.
* Fedor: having a call with V8 might be helpful.
* Mikeal: if it doesn’t happen, then we won’t end up in this situation again.
Conclusion:
Work with V8 team to make sure this doesn’t happen again
Add “un-revert” to the growing list of issues that would trigger a minor version bump.
### Next meeting
*

92
doc/tsc-meetings/io.js/2015-03-18.md

@ -1,92 +0,0 @@
# io.js TC Meeting 2015-03-18
## Links
* **Public YouTube feed**: http://www.youtube.com/watch?v=tQwVcuYCiZ4
* **Google Plus Event page**: https://plus.google.com/events/cneon2drmol62u4drm8aegjnrkk
* **GitHub Issue**: https://github.com/nodejs/io.js/issues/1187
* **Original Minutes Google Doc**: https://docs.google.com/document/d/1It6PTEBQ7OjW8P88hCLoXvcWKA3Q8dY2eYEHIF6FvS4
## Agenda
Extracted from https://github.com/nodejs/io.js/labels/tc-agenda prior to meeting.
* [#1134](https://github.com/nodejs/io.js/pull/1134) Add Docker working group
* [#1140](https://github.com/nodejs/io.js/pull/1140) Revert stream base / @piscisaureus / merge policy questions
* [#1130](https://github.com/nodejs/io.js/pull/1130) Nominating Jeremiah Senkpiel @Fishrock123 to the TC
* [#1077](https://github.com/nodejs/io.js/pull/1077) Pass args to process.nextTick() / @trevnorris
## Minutes
### Present
* Ben (TC)
* Bert (TC)
* Chris (TC)
* Fedor (TC)
* Trevor (TC)
* Rod
### Mini stand-up
* Ben: reviewing bugs, fixing pull requests
* Bert: debugging Windows issues (related to #1005), working on a more helpful CI dashboard
* Chris: working on tools to inspect amount of ecosystem breakage that changes cause
* Fedor: working through PayPal leak issue, working on net.socket() changes
* Rod: ..
* Trevor: misc PRs, process.nextTick(), timer bug
### Review of last meeting
* lib: fix process.send() sync i/o regression [#774](https://github.com/nodejs/io.js/issues/774) / @bnoordhuis
* iojs: introduce internal modules [#848](https://github.com/nodejs/io.js/issues/848) / @chrisdickinson / @trevnorris / (@vkurchatkin)
* url: significantly improve the performance of the url module [#933](https://github.com/nodejs/io.js/issues/933) / @mikeal
* Ship websockets in core [#1010](https://github.com/nodejs/io.js/issues/1010) / @piscisaureus
* RFC: upgrade to V8 4.2? [#1026](https://github.com/nodejs/io.js/issues/1026) / @bnoordhuis
* Colin resigning from TC [#1056](https://github.com/nodejs/io.js/pull/1056)
### [#1134](https://github.com/nodejs/io.js/pull/1134) Add Docker working group
* Rod: originally conceived to be a “sub-WG” of Build WG but this makes sense because there is little overlap with the Build team or skills required for the Build team.
* Rod: this group is already maintaining official Docker images or io.js located at https://github.com/nodejs/docker-iojs which are also the “official” Docker images for io.js.
### [#1140](https://github.com/nodejs/io.js/pull/1140) Revert stream base / @piscisaureus / merge policy questions
* Bert: in favour of stream_base now and don’t want it reverted given the fixes that have been made. The real problem was the introduction of a major change that lead to a lot of breakage and a lot of fix commits. Proposed that we have a “ng” (or similar) branch with releases for testing before merging.
* Chris: agree that we need a canary policy of some kind to deal with this
* Bert: feature flags are a good way of dealing with this and letting them test changes
* Ben: time-based releases like Rust and Chrome
* Fedor: main problem is that we didn’t have enough tests for this feature when it was merged.
* Rod: there’s awkwardness around releasing given that we only have one tip and we can’t cut patch releases once we have semver-minor changes are merged.
* Trevor: should have semver-minor branches where patch fixes go in and minor changes go in to master/whatever.
* Discussion about git process
* Discussion about semver
* Discussion about minor/patch and what it communicates
* Discussion about test coverage
* Rod asked OpenSSL fix: agreed to punt on a release until OpenSSL fix has been released and go immediately after that.
### [#1130](https://github.com/nodejs/io.js/pull/1130) Nominating Jeremiah Senkpiel @Fishrock123 to the TC
* Rod: there was some off-record discussion about TC membership process related to #1130 and #1131.
- Neither individual was asked and it would be good to at least have it passed by them first
- Would be good to have a smooth on-boarding mechanism to bringing someone on to meetings before officially making them TC, agreed to invite Jeremiah to next TC _if_ he’s interested in being involved.
- Generally agreed that increasing the size of the TC is a good thing (minus the meeting-overhead added by more people)
### [#1077](https://github.com/nodejs/io.js/pull/1077) Pass args to process.nextTick() / @trevnorris
* Trevor: passing arguments / context through process.nextTick() in core is common and would be significantly faster if we use a setArgs() feature.
* Chris: needed in readable-stream
* Discussed API concerns and how underscored methods still become defacto in userland
* Chris: could land the internal-module PR and use a Symbol for setArg
* Trevor: major speed increase comes from flattening the call-structure, there’s no additional stack entries for passing arguments. Particularly in crypto, nextTick() is called a lot.
* Rod: we need perf numbers from a user-experience perspective, perhaps that will make it more compelling to merge or perhaps it will make this look trivial that it’s not worth the cost of introducting ugly API
* Trevor: will go off and come back with numbers
### Major version bump
* Ben: proposed making a new integration branch to merge all of the semver-minor features, plus a V8 upgrade, we can start pushing out nightly-style releases for playing around and punt the decision on _how_ to do a major release down the road a little.
* Group agreed, Rod agreed to help come up with a release mechanism for nightlies to couple with this.
### Next meeting
* 25th March 2015

107
doc/tsc-meetings/io.js/2015-04-01.md

@ -1,107 +0,0 @@
# io.js TC Meeting 2015-04-01
## Links
* **Public YouTube feed**: http://www.youtube.com/watch?v=B1pTT60E73M
* **Google Plus Event page**: https://plus.google.com/events/cneon2drmol62u4drm8aegjnrkk
* **GitHub Issue**: https://github.com/nodejs/io.js/issues/1311
* **Original Minutes Google Doc**: https://docs.google.com/document/d/1iEzSiQpB3me-x1R0_FzlMtGuPmgxR2x7NMITp779690
## Agenda
Extracted from https://github.com/nodejs/io.js/labels/tc-agenda prior to meeting.
* reconciliation update (Mikeal and Bert)
* doc: add NAN WG [#1226](https://github.com/nodejs/io.js/issues/1226)
* Proposal: Authorise @Fishrock123 to create releases [#1225](https://github.com/nodejs/io.js/issues/1225)
* governance: Raise the bar for changes in membership and governance policy [#1222](https://github.com/nodejs/io.js/issues/1222)
* Nominating Rod Vagg @rvagg to the TC [#1134](https://github.com/nodejs/io.js/issues/1131)
## Minutes
### Present
* Ben (TC)
* Bert (TC)
* Chris (TC)
* Domenic
* Fedor (TC)
* Jeremiah
* Mikeal
* Trevor (TC)
* Rod
### Mini stand-up
* Ben: rewriting the timers module
* Bert: making it possible to rename node.exe/iojs.exe (made it into 1.6.3); governance documents for Node Foundation
* Chris: building a UTF-8 consumer that can validate/skip invalid glyphs; working on a tool around control flow analysis
* Domenic: not much io.js related
* Fedor: rewrote io.js in Go, deciding whether it should be go.io or io.go
* Jeremiah: managing issues, reviewing PRs, investigating timers bugs
* Mikeal: io.js charter / Linux foundation work
* Trevor: looking into beforeExit/timer unref/uv_loop_alive interactions; Node API compliance working group docs (not io.js ... might be fed into the Foundation)
* Rod: released 1.6.3; GitHub DDOS and CI errors/timeouts are frustrating
### Review of last meeting
* [#1134](https://github.com/nodejs/io.js/pull/1134) Add Docker working group
* [#1140](https://github.com/nodejs/io.js/pull/1140) Revert stream base / @piscisaureus / merge policy questions
* [#1130](https://github.com/nodejs/io.js/pull/1130) Nominating Jeremiah Senkpiel @Fishrock123 to the TC
* [#1077](https://github.com/nodejs/io.js/pull/1077) Pass args to process.nextTick() / @trevnorris
* Major version bump
### Reconciliation update (Mikeal and Bert)
* Mikeal: getting close to a really good position where the governance structures can be merged between io.js and joyent/node. New working group structure and relationship with “TSC”. People can engage @ https://github.com/joyent/nodejs-advisory-board/ with active PRs @ https://github.com/joyent/nodejs-advisory-board/pull/30 & https://github.com/joyent/nodejs-advisory-board/pull/33
* Bert: discussed why this is good for io.js:
- io.js still has a very low profile, merging would be good for everyone
- budget from corporate backers, including the ability to travel
* Mikeal: added to those comments: institutional backing would be very helpful at this stage
* Ben: current PR seems to give the board more influence than originally suggested
* Mikeal: the intent is the board is not to make technical decisions, the TSC is
* Trevor: counterpoint example is IBM maintaining their own fork of V8 so they may want influence on the release process
* Mikeal: they will be taken care of by an LTS schedule
* Bert: IBM agrees that there should be a fast-moving tip and they just use an LTS. Board could also assert influence by way of a corporation threatening to withdraw backing.
### doc: add NAN WG [#1226](https://github.com/nodejs/io.js/issues/1226)
* Rod: discussed proposed move of rvagg/nan and rvagg/node-addon-examples to iojs to be governed by an “Addons API Working Group”
Bert: +1
Chris: +1
Fedor: +1
Ben: +1
Trevor: +1
### Proposal: Authorise @Fishrock123 to create releases [#1225](https://github.com/nodejs/io.js/issues/1225)
* No disagreement, lots of +1s, good to go
### governance: Raise the bar for changes in membership and governance policy [#1222](https://github.com/nodejs/io.js/issues/1222)
* Mikeal: the PR is a bit stale because of a miscount, just want to make sure that there are no concerns with this even though it may not end up being required given the movements with the TC.
* Rod: requested that we not hold up progress in io.js pending movement on the JNAB / Foundation process and we should treat that as a separate thing that may or may not happen.
* Bert: happy with the changes but can’t +1 because of the TC company proportion counting
* Mikeal: just a miscount, needs to be changed, wanted to test if people are OK with this once we have more people on the TC. Main point was to flush out any concerns about raising the bar.
* Ben: suggested that it become 2 PRs, make the 2/3rds thing a separate issue.
### Nominating Rod Vagg @rvagg to the TC [#1134](https://github.com/nodejs/io.js/issues/1131)
* Rod: fine with this
* Discussed meeting facilitation, agreed that it wasn’t a strictly defined role but it would be good to share it around a bit.
Bert: +1
Chris: +1
Fedor: +1
Trevor: +1
Ben: +1
### Open to QA from IRC
_Nothing clear to discuss, but we’ll keep trying this_
### Next meeting
* 8th April 2015

184
doc/tsc-meetings/io.js/2015-04-08.md

@ -1,184 +0,0 @@
# io.js TC Meeting 2015-04-08
## Links
* **Public YouTube feed**: http://www.youtube.com/watch?v=OjlK8k10oyo
* **Google Plus Event page**: https://plus.google.com/events/c1c3234uog6svplgrapqucb557k
* **GitHub Issue**: https://github.com/nodejs/io.js/issues/1369
* **Original Minutes Google Doc**: https://docs.google.com/document/d/1EsDjfRGpVKFABH4LcNXNxsAsBTnHsU-i5cehmAcp1A8
## Agenda
Extracted from https://github.com/nodejs/io.js/labels/tc-agenda prior to meeting.
* [#1101](https://github.com/nodejs/io.js/pull/1101) http: allow HTTP to return an HTTPS server / @silverwind / the use of a `tls` option to trigger `https` module functionality
* [#1301](https://github.com/nodejs/io.js/pull/1301) Util(.is*) Deprecations / @Fishrock123 & @brendanashworth / [this comment](https://github.com/nodejs/io.js/pull/1301#issuecomment-90829575) asking for an opinion from the TC on how to move forward
* Discuss https://github.com/jasnell/dev-policy [[comment by @mikeal]](https://github.com/nodejs/io.js/issues/1369#issuecomment-90955688)
* Discuss / Review the `require(‘.’)` situation [[comments by @silverwind and @Fishrock123]](https://github.com/nodejs/io.js/issues/1369#issuecomment-90933134)
### Present
* Bert (TC)
* Domenic
* Trevor (TC)
* Ben (TC)
* Fedor (TC)
* Jeremiah
* Mikeal
* Chris (TC)
### Review of last meeting
* reconciliation update (Mikeal and Bert)
* doc: add NAN WG [#1226](https://github.com/nodejs/io.js/issues/1226)
* Proposal: Authorise @Fishrock123 to create releases [#1225](https://github.com/nodejs/io.js/issues/1225)
* governance: Raise the bar for changes in membership and governance policy. [#1222](https://github.com/nodejs/io.js/issues/1222)
* Nominating Rod Vagg @rvagg to the TC [#1134](https://github.com/nodejs/io.js/issues/1131)
### Quick stand-up
* Ben: fixing bugs, reviewing PRs. Looked into adding `Generator.prototype.return()` in V8, but more complicated than expected (crashes and can’t figure out why). Fedor might help.
* Bert: working on a CI status dashboard. Reviewing a patch that makes Node use Chakra instead of V8 (!)
* Chris: worked on a patch to add a UTF8 consumer to utils, for the purposes of eventually adding UTF8 validation as well as being able to externalize buffer-strings. Talked about standardizing destroy() behavior on streams
* Domenic: Not much on io.js, reviewed some dev policy stuff especially with regard to V8
* Fedor: bugs and PRs
* Jeremiah: bugs and PRs and 1.6.4 release
* Mikeal: worked on dev policy for the foundation, continuing to iterate; distilling feedback from worried-about-reconciliation thread, but had to lock it in the end with links to other places to address such things.
* Trevor: code reviews
## Minutes
### [#1101](https://github.com/nodejs/io.js/pull/1101) http: allow HTTP to return an HTTPS server
***@silverwind / the use of a `tls` option to trigger `https` module functionality***
Jeremiah: two options we have (that we’ve discussed) are a tls option, or just auto-detect if you provide appropriate options.
Ben: why is this a TC issue?
Jeremiah/Domenic: three or four weeks without consensus.
Mikeal: related to issue in NG, where you could pass options to listen() instead of createServer().
Chris/Jeremiah: there is a PR for it in joyent/node; not merged yet.
Fedor: to me the problem is `http.request` vs. `https.request`.
Mikeal: (advocates for .listen again)
Trevor: -1 for doing it .listen; it’s too complicated internally; there is lots of weirdness going on here already.
Fedor: would be harder to share a server among workers in a cluster.
DD: but this particular PR is just a simple change to allow you to avoid having to decide between require('http') vs. require('https').
Bert: I kind of like the version where you put the options in listen().
Ben: what happens when iojs is compiled without TLS support?
**Conclusion**: punt on this. Initial feedback is that if we were to go down this route, we would slightly prefer the explicit tls option; however, there needs to be a discussion about the listen() idea, and also about compilation without TLS.
### [#1301](https://github.com/nodejs/io.js/pull/1301) Util(.is*) Deprecations
***@Fishrock123 & @brendanashworth / [this comment](https://github.com/nodejs/io.js/pull/1301#issuecomment-90829575) asking for an opinion from the TC on how to move forward***
Bert: what’s the point?
Trevor: that we won’t really fix bugs in these.
Mikeal: this is just in the docs?
Ben: also util.deprecate to log a warning
Mikeal: that just sounds annoying
Trevor: it’s supposed to be; fix your code
Mikeal: yeah but it’s not always your code…
Bert: we already have two levels of deprecation, warning and not warning
Domenic: however we only use the latter for domains, since we don’t have an alternative for them
Mikeal: can we do staged deprecations, marking things in the docs for one major release cycle, then in the next major release cycle start warning
Domenic: could we add an option to show the deprecation warnings for people who are contentious?
Mikeal: I don’t think anyone would actually turn that on…
Chris: I might be able to run my tooling over all of npm to detect uses
Bert: we need a better strategy in general for moving things out of core. The reason we want to deprecate these is that we don’t really want to fix it because that would be backward incompatible, so this is really too big to be in core. Any ideas for making these better? Maybe if you install a module called util it can take precedence over the one in node? So then we can release the fixed one on npm?
Mikeal: that does sound better than versioning core modules … we hit a flag that lets you replace the core one with a new one. Over time we’ll be able to get data.
Bert: there were some talks about doing this in browsers?
Domenic: not really, nobody wants to ship two versions.
**Conclusions: mark util.isXYZ deprecated in the docs, but do not show a warning in the console this version**
### [Dev Policy](https://github.com/jasnell/dev-policy)
Chris: looking good to me, on the right path, some minor issues still being worked out. E.g. around using priority tags and ways to funnel work to smaller number of contributors in joyent/node vs. just adding more contributors as we do.
Jeremiah: Node has a CI Jenkins PR integration thing that they are in favor of using
Domenic: honestly anything that prevents people from committing things that turn the build red would be awesome…
Bert: agree.
Bert: there’s an issue about version numbers
Mikeal: if we merge, it’ll be a 2.0.0, and we’ll bring in the backward incompatible changes we’ve been sitting on for a while
Mikeal: more on this tomorrow, audio will be public after it happens (due to technology being used it won’t be live). Please review dev policy beforehand.
### Isaac
Ben: Isaac doesn’t seem to be involved anymore. What do we do when a TC member goes AWOL?
Mikeal: well, we cancelled two meetings he was ready to attend, and then he went on vacation for two weeks, so AWOL isn’t quite the right characterization… But yeah, he’s not doing too much. We can just ask if he wants to be there, or we can vote it off.
Bert: I asked him and didn’t get an extremely clear answer; we’ll probably get more clarity when he’s back from vacation. I would not suggest throwing him off right now.
Ben: yeah, there’s no urgency, just…
Bert: yes, but I agree that if you’re on the TC you should show up to meetings
Fedor: what if we made votes exponentially decay in power based on attendance…
### `require('.')`
Mikeal: if we knew the impact of this change would we have done a major?
Chris: if we would have done a major we wouldn’t have done it at all because the API is locked and only bugfixes are allowed.
Jeremiah: that being said the only thing that breaks is a strange workflow from an undocumented feature.
Ben: I am not very sympathetic to that argument; we broke someone’s workflow, and that’s bad.
Domenic: I don’t think that’s fair. Every change is breaking to someone; even changing error messages will break people who parse error messages. The question is what side of the line this is on.
Mikeal: it seemed weird…
Domenic: I always thought NODE_PATH was deprecated. Should we warn about people using it?
Ben: I understand that someone is already using the new require behavior, so reverting it would be backward-incompatible. So we have a few options: 1) add a hack that makes NODE_PATH interactions with require('.') work as they used to; 2) say “sorry” and keep as-is
Bert: I’m sympathetic to adding the hack and a warning.
Domenic: agree. And maybe try to kill NODE_PATH in 3.x.
**Conclusion: hack plus a warning that shows up in this hacky case (“hey, you’re using the require-dot trick with NODE_PATH; we made it work because we’re nice people, but we want to take it away in 2.x, so gear up”). In 2.x, probably warn on any use of NODE_PATH at all.**
### Bert shows off his CI prototype
It’s pretty cool.
It groups tests in interesting ways that are useful. (OS, flakiness, …)
### Next meeting
* 2015-04-15

87
doc/tsc-meetings/io.js/2015-04-15.md

@ -1,87 +0,0 @@
# io.js TC Meeting 2015-04-15
## Links
* **Public YouTube feed**: http://www.youtube.com/watch?v=lsRu_of0Xp8
* **Google Plus Event page**: https://plus.google.com/events/cdinisa9mlisv81um91h71g3css
* **GitHub Issue**: https://github.com/nodejs/io.js/issues/1431
* **Original Minutes Google Doc**: https://docs.google.com/document/d/1zlYeYS0LCyIjN4KsjXh9d46hNjp302M6L1K_-_OckzQ
## Agenda
Extracted from https://github.com/nodejs/io.js/labels/tc-agenda prior to meeting.
* [#1393](https://github.com/nodejs/io.js/issues/1393) Ready to upgrade to V8 4.2?
* [#1413](https://github.com/nodejs/io.js/issues/1413) combining TC and Node core call
* [#1416](https://github.com/nodejs/io.js/issues/1416) io.js diff node.js foundation
### Present
* Ben (TC)
* Bert (TC)
* Chris (TC)
* Domenic
* Isaac (TC)
* Jeremiah
* Mikeal
* Rod (TC)
### Review of last meeting
* [#1101](https://github.com/nodejs/io.js/pull/1101) http: allow HTTP to return an HTTPS server
* [#1301](https://github.com/nodejs/io.js/pull/1301) Util(.is*) Deprecations
* [Dev Policy](https://github.com/jasnell/dev-policy)
* Isaac
* [#1365](https://github.com/nodejs/io.js/issues/1356) `require('.')`
### Quick stand-up
* Ben: will be working less on io.js in the coming weeks
* Bert: come clang hacking but not much else
* Chris: some review/work on dev-policy
* Domenic: did some review of the URL work
* Isaac: on vacation and busy re fundraising, probably have less time for io.js into the future, will likely be moved out of the role
* Jeremiah: some issue management, working with dev-policy
* Mikeal: dev-policy and readable summary of the foundation documents
* Rod: lots of build WG work including auto Jenkins runs, write-up on “the state of the build”
## Minutes
### [#1393](https://github.com/nodejs/io.js/issues/1393) Ready to upgrade to V8 4.2?
* Ben: `next` branch should be ready to go though needs to be upgraded to 4.2.77.14, C++ changes are fairly minimal.
* Discussed potentially bumping major:
- Mikeal: there was a meeting where it was generally agreed that an ABI change would warrant a version bump
- Rod & Isaac suggested that ABI changes shouldn’t bump major
- Discussion came around to most members agreeing that ABI change _should_ bump major. Rod voted 0 on this, everyone else apparently +1.
- Discussed semver-major changes including process.send() sync regressions, agreed that https://github.com/nodejs/io.js/milestones/2.0.0 represents the best info on what’s mergable
* Discussed git, agreed that we should move back to master, Chris to handle git changes
* Discussed RC build, could use nightly or next-nightly but officially link it off the website and maybe label it differently. Rod to figure this out.
Actions:
- Isaac to further review url changes, aside from his review and Domenic’s feedback in there it should be ready to merge
- Chris to handle git and a move back to master
- Ben to PR next branch back into master
- Rod to figure out how to do and publish an RC build that’s not just “nightly-xxxxxxxxxxxxxx”
- Chris will test packages against URL PR and write up results
### [#1413](https://github.com/nodejs/io.js/issues/1413) combining TC and Node core call
* Mikeal: last dev-policy call brought up the suggestion of combining TC calls for both projects, with an eye on merging it would be good to understand what both groups do. Single meeting for both would be good.
* Discussed timing - we span more timezones than they do so our slot of 1pm PST makes more sense to get Rod and Fedor in at the same time. Could either be Tue or Wed UTC, they have a meeting the day before us.
* No strong disagreement
### [#1416](https://github.com/nodejs/io.js/issues/1416) io.js diff node.js foundation
* Mikeal: Foundation doc is huge compared to ours and also contains some formalisation of our process that we just haven’t formalised yet. The diff contains a lot of those and some _actual_ changes too. Open for discussion amongst the community.
* Rod: LTS discussion starting next week.
## QA on Freenode/#io.js
* Paused for input, nothing this week, will continue to offer a time for this.
## Next meeting
* FluentConf is on next week, Bert, Mikeal and Isaac will be at that. Agreed to go ahead and schedule one anyway.
* 2015-04-22

127
doc/tsc-meetings/io.js/2015-04-22.md

@ -1,127 +0,0 @@
# io.js TC Meeting 2015-04-22
## Links
* **Public YouTube feed**: http://www.youtube.com/watch?v=s7LIMsTFaps
* **Google Plus Event page**: https://plus.google.com/events/co7i7pv2a51270jat7jvkfcue64
* **GitHub Issue**: https://github.com/nodejs/io.js/issues/1502
* **Original Minutes Google Doc**: https://docs.google.com/document/d/1G4aJ2OwiW2WphW7Vz2OW56VRot8xRBFitluKsuYPxk0
## Agenda
Extracted from https://github.com/nodejs/io.js/labels/tc-agenda prior to meeting.
* [#1130](https://github.com/nodejs/io.js/issues/1130) Nominating Jeremiah Senkpiel @Fishrock123 to the TC
* [#1481](https://github.com/nodejs/io.js/issues/1481) Nominating @mikeal to the TC
* [#1500](https://github.com/nodejs/io.js/issues/1500) Nominating Brian White @mscdex to the TC
* [#1501](https://github.com/nodejs/io.js/issues/1501) Nominating Shigeki Ohtsu @shigeki to the TC
* [#1393](https://github.com/nodejs/io.js/issues/1393) Ready to upgrade to V8 4.2?
* [#1413](https://github.com/nodejs/io.js/issues/1413) Combined node.js/io.js TC/Core Call
* [#1416](https://github.com/nodejs/io.js/issues/1416) Diffing io.js and the Node.js Foundation
### Present
* Ben (TC)
* Bert (TC)
* Brian
* Chris (TC)
* Domenic
* Fedor (TC)
* Jeremiah
* Shigeki
* Trevor (TC)
* Rod (TC)
### Review of last meeting
* [#1393](https://github.com/nodejs/io.js/issues/1393) Ready to upgrade to V8 4.2?
* [#1413](https://github.com/nodejs/io.js/issues/1413) combining TC and Node core call
* [#1416](https://github.com/nodejs/io.js/issues/1416) io.js diff node.js foundation
### Quick stand-up
* Ben: Not much, company stuff
* Bert: Playing with clang and FFI, FluentConf
* Brian: JS HTTP parser, optimising and messing with regex
* Chris: URL changes, looking for breakage, checked on newSession/resumeSession, 1.8.x release
* Domenic: Not much, some work on V8 extensions with possible news next weeks
* Fedor: Looking at the “debugger is slow” in WebStorm issue, possible fix to V8 soon, working on using the OpenSSL 1.0.2 hello parser, HTTP parser patch review
* Jeremiah: Not so much work on io.js, helped get 1.8.1 out and looking into moving npm out of our git repo.
* Rod: CI cluster dramas around 1.8.x release, new Raspberry Pis
* Shigeki: OpenSSL upgrade, ALPM enabling PR coming this week
* Trevor: Has been testing re-implementing Buffers using ES6 and TypedArrays. Some trickiness but seems doable and with patches that avoid zero-filling, performant.
## Minutes
### [#1130](https://github.com/nodejs/io.js/issues/1130) Nominating Jeremiah Senkpiel @Fishrock123 to the TC
Voted:
* Ben: +1
* Bert: +1
* Chris: +1
* Fedor: +1
* Rod: +1
* Trevor: +1
**Action: Jeremiah Senkpiel is now a member of the io.js Technical Committee!**
### [#1481](https://github.com/nodejs/io.js/issues/1481) Nominating @mikeal to the TC
* Bert, Rod: Discussion regarding the potential consequences of expanding the TC and how that might work if a merger with node happens.
Discussed consequences of expansion for merger and for the practicalities of meeting.
### [#1500](https://github.com/nodejs/io.js/issues/1500) Nominating Brian White @mscdex to the TC
_See above_
### [#1501](https://github.com/nodejs/io.js/issues/1501) Nominating Shigeki Ohtsu @shigeki to the TC
_See above_
### [#1393](https://github.com/nodejs/io.js/issues/1393) Ready to upgrade to V8 4.2?
Rod: no formal “RC” builds yet but master is now going out on nightlies, they have a 2.0.0-pre version string now. Discussed whether we want formal RC builds or not. No strong opinions.
Chris: `master` should be active for dev now, `next` should be used for ongoing V8 upgrade builds. Asked if the V8 changes were ready in `next` to merge - Ben confirmed - Chris to merge.
Trevor: would like to get started on the upcoming V8 Buffer-related breakage and whether we should go to a 2.x branch and work on `master`.
Chris: we should work on new stuff on `next` instead and leave `master` intact for now.
Rod: status of URL parser changes?
Chris: would like to test against candidate modules in npm that may cause breakage but otherwise seems good to merge.
Domenic: would like there to be getters and setters for all data properties for completeness and future-proofing - still to be done
Rod: any other breaking changes worth discussing?
Ben: process.send() ready but not merged, any objections? - no objections.
Chris: https://github.com/nodejs/io.js/milestones/2.0.0 new label “land-on-master” to indicate PRs that are still targeting the v1.x branch.
Ben & Bert discussed Ben’s possible timers rewrite - Ben implemented a heap and red-black tree in JS, turned out to be a bit faster but not complete yet and Ben has been distracted on other projects. **
### [#1413](https://github.com/nodejs/io.js/issues/1413) Combined node.js/io.js TC/Core Call
Bert: probably not this week, intent is for next week.
Jeremiah: there had been discussion around forming a convergence WG to handle some of this so as to not require everyone’s time except when necessary.
### [#1416](https://github.com/nodejs/io.js/issues/1416) Diffing io.js and the Node.js Foundation
_Nothing new to discuss_
## Open QA on Freenode/#io.js
Discussion on merger and how the possibility of merging may hold up progress in io.js. Generally agreed that we shouldn’t stop doing what we are doing, nor slow down progress. Bert would like us to be conscious of activities in the Foundation and how they may impact on what we are doing.
Discussion about “production ready” - recommendation is to use latest, we follow semver so that should be enough information. Rod suggested not jumping straight on to 2.0 when it lands, just because of potential edge-cases around internal changes like the url parser.
Discussed module integration testing to test certain modules that we would test with each release - Chris working on some tooling around being able to inspect what modules are impacted by changes - no specific work on actually running tests on modules but this could be a TODO for Build WG (Rod to make an issue for this).
## Next meeting
* 2015-04-29, UTC 20:00

101
doc/tsc-meetings/io.js/2015-04-29.md

@ -1,101 +0,0 @@
# io.js TC Meeting 2015-04-29
## Links
* **Public YouTube feed**: http://www.youtube.com/watch?v=-e675TT4WEA
* **Google Plus Event page**: https://plus.google.com/events/cei87pqnichrtt4qggbbo656bpk
* **GitHub Issue**: https://github.com/nodejs/io.js/issues/1557
* **Original Minutes Google Doc**: https://docs.google.com/document/d/1C9nfm_5EhNz1jifITbtQcnGBX4R9vktoZ9KsFiCU7sQ
## Agenda
Extracted from https://github.com/nodejs/io.js/labels/tc-agenda prior to meeting.
* Release Proposal: v2.0.0 [#1532](https://github.com/nodejs/io.js/pull/1532)
* Forward-port from v1.x [#1559](https://github.com/nodejs/io.js/pull/1559)
* Convergence plan (https://github.com/jasnell/dev-policy/pull/66)
* Combined node.js/io.js TC/core call about convergence doc [#1413](https://github.com/nodejs/io.js/issues/1413)
### Present
* Ben (TC)
* Bert (TC)
* Brian
* Chris (TC)
* Domenic
* Fedor (TC)
* Jeremiah
* Shigeki
* Trevor (TC)
### Review of last meeting
* [#1130](https://github.com/nodejs/io.js/issues/1130) Nominating Jeremiah Senkpiel @Fishrock123 to the TC
* [#1481](https://github.com/nodejs/io.js/issues/1481) Nominating @mikeal to the TC
* [#1500](https://github.com/nodejs/io.js/issues/1500) Nominating Brian White @mscdex to the TC
* [#1501](https://github.com/nodejs/io.js/issues/1501) Nominating Shigeki Ohtsu @shigeki to the TC
* [#1393](https://github.com/nodejs/io.js/issues/1393) Ready to upgrade to V8 4.2?
* [#1413](https://github.com/nodejs/io.js/issues/1413) Combined node.js/io.js TC/Core Call
* [#1416](https://github.com/nodejs/io.js/issues/1416) Diffing io.js and the Node.js Foundation
### Quick stand-up
* Ben: nothing
* Bert: nothing
* Brian: finished optimizations for JS HTTP parser, posted a few questions; other miscellaneous improvements in core HTTP.
* Chris: upgraded V8 and documented the process; also did some work on the REPL so that classes (and let/const) work
* Domenic: PR reviews for v2.0.0, starting on V8 extension work to improve startup time
* Fedor: worked on fixing some TLS memory issues, so far appears to be a large improvement in memory usage.
* Jeremiah: issue management; discussions on moving npm out of the repo, which seems to have converged toward a helper tool instead of moving it out of the repo
* Mikeal: connection too bad to stand up.
* Shigeki: working on SSL issues; root cert updates. Chrome and Firefox do whitelist of CNNIC cert hashes.
* Trevor: looking at bugs, streams compliance
## Minutes
### Release Proposal: v2.0.0 [#1532](https://github.com/nodejs/io.js/pull/1532)
* Domenic:
- v8 changes merged
- worried that we’re getting into a bad cycle of “wait a few more days” for things to land
- process.send
- open an rc, add to website for a few days, ship by friday
* Bert/Ben:
- talk of process.send
- Ben: should not hold up release, windows tests break right now
- less of a regression than a change
* Domenic:
- these releases are a train
- don’t hold up the train for features
- make sure it’s ready for 3
* url updates from petka: might be ready
- ci run passes on all platforms but arm7
* Domenic recalls in the runup to 1.0 – “nobody tests rc's” was the consensus
Chris, Trevor: discussion about how the `master` and `next` branches are used.
* process.send changes will slip for v2.0
* waiting for Petka’s comment and review on url changes (https://github.com/nodejs/io.js/pull/1561)
* release 2.x asap (friday)
After the release:
* the master branch will contain version 2.x.
* api-breaking changes will land on the ‘next’ branch alongside v8 upgrades. master will be merged into next regularly
* fixes are backported to the maintenance (v1.x) branch
### Forward-port from v1.x [#1559](https://github.com/nodejs/io.js/pull/1559)
Discussed current plan for backporting patches to maintenance patches.
* Consensus that we should give the “land in master and backport” plan a go and see how it works out.
### Convergence plan (https://github.com/jasnell/dev-policy/pull/66)
### Combined node.js/io.js TC/core call [#1413](https://github.com/nodejs/io.js/issues/1413)
## Next meeting
* April 6th

137
doc/tsc-meetings/io.js/2015-05-13.md

@ -1,137 +0,0 @@
# io.js TC Meeting 2015-05-13
## Links
* **Public YouTube feed**: http://www.youtube.com/watch?v=UbYiFLf7MpU
* **Google Plus Event page**: https://plus.google.com/events/cu606mlllfehl11u8kcj7q2407k
* **GitHub Issue**: https://github.com/iojs/io.js/issues/1689
* **Original Minutes Google Doc**: https://docs.google.com/document/d/15Y_kJlYm-8cIf-alniaqUWMM-TjGISCqLf40G3pv4sM
## Agenda
Extracted from https://github.com/iojs/io.js/labels/tc-agenda prior to meeting.
* V8 4.4 to remove indexed properties via external data [#1451](https://github.com/iojs/io.js/issues/1451)
* NODE_PATH deprecation [#1627](https://github.com/iojs/io.js/issues/1627)
* Join the Node Foundation? [#1664](https://github.com/iojs/io.js/issues/1664)
* Put `*Sync` methods behind a flag in some future major version [#1665](https://github.com/iojs/io.js/issues/1665)
* TC Nominations
- Shigeki Ohtsu @shigeki [#1501](https://github.com/iojs/io.js/issues/1501)
- Brian White @mscdex [#1500](https://github.com/iojs/io.js/issues/1500)
- @mikeal [#1481](https://github.com/iojs/io.js/issues/1481)
* Public QA via #io.js channel on Freenode
### Present
* Ben (TC)
* Bert (TC)
* Brian
* Chris (TC)
* Domenic
* Jeremiah (TC)
* Mikeal
* Rod (TC)
* Shigeki
* Trevor (TC)
### Quick stand-up
* Ben: Upgraded V8, upgraded cares for the first time in 2 years, reviewed pull requests
* Bert: Played Keen, not much io.js stuff; last Monday met with James, Mikeal about convergence
* Brian: looking over potential optimizations in the JS codebase, started working on a DNS resolver as a potential replacement for cares
* Chris: fixing race conditions in the REPL, poking at adding Ctrl-R history searching to readline
* Domenic: working with V8 team in Munich, working on v8-extras feature, putting large portions of things into snapshot to speed up startup and other things: https://groups.google.com/forum/#!topic/v8-users/D6FmTwlvCgk
* Jeremiah: issue management, working on tooling for automatic dependency upgrades, see [#1688](https://github.com/iojs/io.js/pull/1688)
* Mikeal: Foundation stuff, getting ducks in a row
* Shigeki: holiday in JP, fix TLS bug involving edge-case, needs review
* Trevor: Helped with re-enabling snapshots, looking at changing the Buffer APIs to use TypedArrays
* Rod: Been doing lots of little things, working on the CI and build cluster
### Review of last meeting
* Release Proposal: v2.0.0 [#1532](https://github.com/iojs/io.js/pull/1532)
* Forward-port from v1.x [#1559](https://github.com/iojs/io.js/pull/1559)
* Convergence plan (https://github.com/jasnell/dev-policy/pull/66)
* Combined node.js/io.js TC/core call [#1413](https://github.com/iojs/io.js/issues/1413)
## Minutes
* Discussed creating a more formal deprecation policy, chris to open an issue.
### V8 4.4 to remove indexed properties via external data [#1451](https://github.com/iojs/io.js/issues/1451)
* ‘smalloc’ has to go away when we land this V8, thankfully it’s not been around for long but this is a forced deprecation & removal.
* currently usage of ‘smalloc’ gives a deprecation warning, as of v2.0.0
* @jeisinger has been backporting some APIs needed for Buffer, NAN will have to catch up but @kkoopa is involved
* Domenic: V8 4.3 will be next week, 7 weeks from now will be 4.4 (~1 week behind Chrome release)
* Trevor: no major problems with JS API, most problems will be in the C++ API, should be able to shim to ease it
### NODE_PATH deprecation [#1627](https://github.com/iojs/io.js/issues/1627)
* Jeremiah: there was a suggestion to deprecate NODE_PATH entirely, debate is over deprecation or not, lots of people appear to be finding novel uses of it.
* Domenic: maybe we should document it
* Chris: it is documented, Googling shows that it’s been ingrained into the Node background, there’s lots of info out there about how it’s used
* Domenic: https://iojs.org/api/modules.html#modules_loading_from_the_global_folders
* Mikeal: maybe write docs about how it exists but you shouldn’t use it
**Action: Mikeal to open an issue to change the docs to talk about how you probably shouldn’t use them** (note: it might be as simple as styling!)
### Join the Node Foundation? [#1664](https://github.com/iojs/io.js/issues/1664)
* Mikeal: Mostly a consensus in the issue about joining
* Mikeal: Next step is to move the “iojs” org to “nodejs”, then move the convergence repo in to be “node” to be the new tip: https://github.com/jasnell/node.js-convergence
Lots of discussions about process and what needs to happen & when, Mikeal pushing for a vote to get the org moved.
**Voting Question**: The io.js TC agrees to:
1. have the io.js project join the Node Foundation
2. rename the entire “iojs” GitHub org to be “nodejs”
3. invite the the current Node.js TC on to our TC to form the basis of a Node Foundation TSC under the policies of the Node Foundation
4. moving the io.js Working Groups to be under the Node Foundation
**Voting Results**:
* Fedor: 0
* Ben: +1
* Bert: +1
* Chris: +1
* Jeremiah: +1
* Trevor: +1
* Rod: +1
Action: Mikeal to make the move happen in a coordinated way so we get redirects and whatnot
### Put `*Sync` methods behind a flag in some future major version [#1665](https://github.com/iojs/io.js/issues/1665)
* Ben: some people feel that `fs.*Sync()` methods are harmful and would like to see them go away and be behind a flag
* Bert: don’t agree with deprecating but agree with a flag
* Rod: agree with Bert, but would like to see doc changes
* Trevor: working on a flag to print a stack trace
### TC Nominations
* Shigeki Ohtsu @shigeki [#1501](https://github.com/iojs/io.js/issues/1501)
* Brian White @mscdex [#1500](https://github.com/iojs/io.js/issues/1500)
* @mikeal [#1481](https://github.com/iojs/io.js/issues/1481)
* Mikeal: joining
* Rod: timing is awkward with convergence but I’d like to make sure that Shigeki and Brian have a path to join the TC and not have that delayed too much
### Public QA via #io.js channel on Freenode
* `<therebelrobot> After the converged release, will io.js/node still be semver? for example, the history would be node 0.10, 0.12, iojs 1.x 2.x then the converged one would be node 3.x?`
- Mikeal: the dev policy says so, there’s nobody advocating not to
* `<evanlucas> Are there plans to symlink node to iojs in the installers after the first converged release?`
- Bert: undecided. We should figure out a way to allow users to “node lts” and “node bleeding edge” side by side.
- Mikeal: part of the above is covered by a thread in NG about localizing the node installation to global modules.
* `<phpnode> will members of the core team be able to revive io.js if they disagree with the direction of the project in future`
- (Group) Yes
* `<skinan5> any plans for nan resolution?`
- Rod: it’s just a header file and you need it for older versions of Node so it doesn’t make sense to _not_ use it from npm
- Ben: current NAN isn’t suitable for bringing in
- Trevor: would support bringing in something that would provide proper ABI support
- Action: Trevor to open an issue on the NAN repo to talk about a stable C++ layer
## Next meeting
* May 20th, invite joyent/node TC members, figure out who that is and if this timeslot works for them when we have a combined call tomorrow (14th)
Loading…
Cancel
Save