Node.js Foundation Technical Steering Committee (TSC) Meeting 2018-09-19

[mhdawson]

Time

UTC Wed 19-Sep-2018 16:00 (04:00 PM):

Timezone	Date/Time
US / Pacific	Wed 19-Sep-2018 09:00 (09:00 AM)
US / Mountain	Wed 19-Sep-2018 10:00 (10:00 AM)
US / Central	Wed 19-Sep-2018 11:00 (11:00 AM)
US / Eastern	Wed 19-Sep-2018 12:00 (12:00 PM)
London	Wed 19-Sep-2018 17:00 (05:00 PM)
Amsterdam	Wed 19-Sep-2018 18:00 (06:00 PM)
Moscow	Wed 19-Sep-2018 19:00 (07:00 PM)
Chennai	Wed 19-Sep-2018 21:30 (09:30 PM)
Hangzhou	Thu 20-Sep-2018 00:00 (12:00 AM)
Tokyo	Thu 20-Sep-2018 01:00 (01:00 AM)
Sydney	Thu 20-Sep-2018 02:00 (02:00 AM)

Or in your local time:

• http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+Technical%20Steering%20Committee%20(TSC)+Meeting+2018-09-19&iso=20180919T16
• or http://www.wolframalpha.com/input/?i=04PM+UTC%2C+Sep+19%2C+2018+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/1o4ZIw1gxEcSstJfWv9qM3R_DiIP40lMqghzvTLY2wmY/edit

Agenda

Extracted from tsc-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

nodejs/node

• how to do feature detection #22585
• [WiP] buffer: runtime-deprecate buffer constructor in sync mode #22584
• process: add resolveSwallowed event #22218
• buffer: runtime-deprecate Buffer constructor everywhere by default #21351

nodejs/TSC

• Tracking issue for updating TSC on Board Meetings #476
• Strategic Initiatives - Tracking Issue #423
• Help in triaging node.js core security issues - Help in triaging node.js core security issues #598

nodejs/admin

• JS Interactive & Node Community Corner - Questions? #211

Invited

• Anna Henningsen @addaleax (TSC)
• Сковорода Никита Андреевич @ChALkeR (TSC)
• Colin Ihrig @cjihrig (TSC)
• Daniel Bevenius @danbev (TSC)
• Franziska Hinkelmann @fhinkel (TSC)
• Gibson Fahnestock @gibfahn (TSC)
• Jeremiah Senkpiel @Fishrock123 (TSC)
• James M Snell @jasnell (TSC)
• Joyee Cheung @joyeecheung (TSC)
• Matteo Collina @mcollina (TSC)
• Michael Dawson @mhdawson (TSC)
• Myles Borins @MylesBorins (TSC)
• Ali Ijaz Sheikh @ofrobots (TSC)
• Rod Vagg @rvagg (TSC)
• Michaël Zasso @targos (TSC)
• Sakthipriyan Vairamani @thefourtheye (TSC)
• Timothy Gu @TimothyGu (TSC)
• Rich Trott @Trott (TSC)

Observers/Guests

Notes

The agenda comes from issues labelled with tsc-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.

Joining the meeting

Zoom link: https://zoom.us/j/611357642
Regular password

Public participation

We stream our conference call straight to YouTube so anyone can listen to it live, it should start playing at https://www.youtube.com/c/nodejs+foundation/live when we turn it on. There's usually a short cat-herding time at the start of the meeting and then occasionally we have some quick private business to attend to before we can start recording & streaming. So be patient and it should show up.

Many of us will be on IRC in #node-dev on Freenode if you'd like to interact, we have a Q/A session scheduled at the end of the meeting if you'd like us to discuss anything in particular. @nodejs/collaborators in particular if there's anything you need from the TSC that's not worth putting on as a separate agenda item, this is a good place for that

Edited by ChALkeR: I took off nodejs/node#21766 from the agenda for now, sorry of inconvenvience. I was the one who labelled it as tsc-agenda some time ago.

[targos]

/cc @apapirovski and @gabrielschulhof

[mcollina]

I've added tsc-agenhttps://github.com//issues/598 to the agenda

[MylesBorins]

Won't be able to make it due to Jewish high holidays

[Trott]

I've added tsc-agenhttps://github.com//issues/598 to the agenda

@mcollina Are you adding it for a decision or for informational purposes? Seems like there's consensus and it can move forward.

[mcollina]

I’m not sure if we needed a vote, happy to remove if it is not needed.

[Trott]

Moderation Team report: No moderation actions to report this week. (Will post again if I'm speaking too soon and something comes up in the next day or two.)

@nodejs/tsc @nodejs/community-committee @nodejs/moderation

[Trott]

For announcements and strategic initiative updates, it would be great if @nodejs/tsc members could put the info in the minutes now so that we can get through those parts of the meeting efficiently.

[Trott]

@nodejs/tsc Please take note:

The 10.11.0 release is blocked (by me, but on behalf of @jasnell, @mcollina, and @joyeecheung) due nodejs/node#22585 so please please please look at that issue (especially starting with nodejs/node#22585 (comment)) and weigh in on feature detection over there. I'd also recommend that it be the issue we start the meeting with tomorrow so as to give it the time it needs to drive to a resolution.

But especially in this issue, weigh in on whether the recursive mkdir stuff should go in the 10.11.0 release as-is or not.

[mcollina]

I’m ok in getting it out. I prefer mkdirp, but I think we can happily have both.

[Trott]

I’m ok in getting it out. I prefer mkdirp, but I think we can happily have both.

I could be wrong, but I'm pretty sure a fs.mkdirp() alias could only happen over the objections of @bengl, @MylesBorins, and probably others. But we'll cross that bridge when we get to it. I've done a strike-through on your handle in the comment above to indicate that you are not opposed to the release. If @jasnell and @joyeecheung are on the same page as you, I'd be happy to see the release go forward with recursive mkdir(). I just don't want anyone to be surprised and feel like they would have blocked it if only they had noticed it happening...

[jasnell]

We shouldn't block the release, but we shouldn't include recursive mkdir in the release at all until we have the discussion a bit more settled.

[mcollina]

I won't be able to be in the first ~30 minutes of the meeting, unfortunately I have a clash.

[Trott]

So, here's the very first thing we should decide at the meeting today. If you are @nodejs/tsc and won't be at the meeting (or even if you will), it would be great if you could register your opinion here. A vote is not inconceivable.

Which of the following two options is the one to take with recursive mkdir in the 10.11.0 release that is scheduled to go out today?

1. Ship it as-is (an options flag on fs.mkdir()) . You might choose this one if you think that's the right way to do it, so we should just ship it. You also might choose this one if you think that feature detection may end up having us add a fs.mkdirp() alias for that option, and you're OK with that.

2. Do not ship it until we figure out how feature detection will work for that feature. You might choose this if you don't want to be stuck supporting the options flag if you think just having fs.mkdirp() alone might be better. You also might choose this option if you think we shouldn't add new features at all until we figure out our feature detection story.

As best as I can tell, option 1 proponents are:

1. @targos
2. @Trott
3. @mcollina
4. @MylesBorins
5. @gabrielschulhof
6. @cjihrig
7. @ofrobots
8. @mhdawson

As best as I can tell, option 2 proponents are:

1. @jasnell
2. @danbev
3. @thefourtheye
4. @Fishrock123

People whose comments I'm interpreting as abstaining:

1. @joyeecheung
2. @apapirovski

Please feel absolutely free to edit this comment to add/remove your handle in either list.

[joyeecheung]

I may be a bit late for today's meeting. In any cases, I will not block the release because of the lack of way to do feature detection.

[joyeecheung]

Also in case I cannot make it: in retrospect I've already done something similar with bigint: true in fs APIs (without aliases) and they are already shipped, so...there's that.

[mhdawson]

In terms of the options on mkdirp I'm for 1.

[apapirovski]

My main objection for mkdirp is that the userbase is much larger than for withFileTypes and bigInt which have been brought up as comparison points. I would prefer option 2 but am fine with 1, although I strongly believe we should have an alias for this specific case.

[targos]

The userbase for a feature is not the same as the userbase for detecting the feature. As it was already brought up in another thread, most people who need mkdirp are not waiting for us to ship it in a release. They also probably haven't written their own implementation but instead are using fs-extra's ensureDir, the mkdirp module or a similar existing npm module. People who care about supporting older Node releases will keep using those modules after we ship the feature. Others will start using it and won't bother checking for its existence (what would they do if the feature isn't available? use a module? why not always use a module, then?). In practice, I expect that only a few people will have to do feature detection (the aforementioned module's authors), so I don't think we need the mkdirp name just for this reason.

[ofrobots]

I'm still forming my opinion on nodejs/node#22585, but that topic a bit broader than the blocking issue for fs.mkdir. I am -1 on a mkdirp alias as this approach doesn't scale. I'm +1 on shipping recursive support as is, as in an options flag.

[mhdawson]

PR for minutes: #603