Repository navigation
Node.js Technical Steering Committee (TSC) Meeting 2020-04-29 #856
Description
Activity
Moderation Team report: Some internal discussions, but no Moderation actions. @nodejs/moderation @nodejs/tsc @nodejs/community-committee
Hi, Strategic Initiative champions! What's your update for this week?
Modules @MylesBorins
Core Promise APIs @mcollina
V8 Currency @targos
QUIC / HTTP3 @jasnell
Startup performance @joyeecheung
Build resources @mhdawsonPromises, we should resolve
process: Throw exception on --unhandled-rejections=default #33021
QUIC ... no significant updates. Working on separating out non-QUIC specific bits from the PR to land separately.
- Build resources
- Nothing to report this week.
- Build resources
I won't be able to attend the TSC meeting this week so want to indicate my positions on the various issues currently on the agenda:
- Dispute of "block running on EOL Windows versions #31954" - Alternative Suggestion #33034
- src,win: Replacement of unsupported versions of Windows runtime exit #33108
These two are related. At issue is the fact that Node.js currently refused to run on older, unsupported versions of Windows. We have a community member who is requesting that we replace that block with a warning, with the understanding that the platform would still be unsupported and that we will not fix any issues that may exist. So far, Ben Noordhuis
has been the only oneand @bzoz have been the only ones I've seen to voice opposition to the idea with caveats. There is a PR moving forward and we need to see if there are any TSC objections. For myself, I am definitely +1 on replacing the current block with a warning.- process: Throw exception on --unhandled-rejections=default #33021
For this issue, I have offered my proposed compromise in this comment: nodejs/node#33021 (comment)
Per last week, the plan has been to put together a survey of the options but I do not believe that has been done yet.
- http: align with stream.Writable #31818
My position on this remains the same. It's something that should move forward as semver-major with coordination with framework developers.
So far, Ben Noordhuis has been the only to voice opposition to the idea.
You're misrepresenting what I said, don't do that. The facts as I see them:
-
The CTC set the current policy after a lot of deliberation and a show of hands.
-
Some people now want to backtrack on that.
-
Fine, but that means it needs to be ratified with another vote.
@jasnell seems to want to push this through in an informal manner, without any kind of quorum.
That seems like a breach of procedure to me. If that's allowed, you can get around TSC decisions by trying a few times until you slip under the radar.
Questions that should be asked and answered:
-
Why backtrack? There are good reasons for the current policy.
-
Why whitelist Windows when we do the same thing on macOS?
Reacted by Colin Ihrig-
It's also worth pointing out a recent comment by @bzoz (one of the top Windows maintainers for both Node and libuv):
I'm -1 on this. Node is not tested on Windows 7, neither is libuv. Having Node run on Win7, with only a warning message - which will be ignored by almost anyone anyway - is asking for trouble in the long run. That said, having a `--skip-supported-platform-check` switch as @jasnell suggested sounds like a reasonable alternative. We should make sure the users know what they are doing before they run Node on an unsupported platform.You're misrepresenting what I said...
Am I?
...I'm closing this as a wontfix.
...The reason I closed this so quickly is that trying to backtrack on it just wastes everyone's time
...I don't want to revisit that discussion
And this...
...seems to want to push this through in an informal manner, without any kind of quorum.
... is silly as I'm not the one who (a) proposed it, (b) reopened the issue, (c) put it on the agenda, or (d) opened the PR. I've offered my opinion on the whether the block should remain, I've encouraged that a concrete proposal (PR) be put forward rather than simply an issue to discuss, and I've acknowledged that there is an outstanding objection to the change that needs to be handled.
...that means it needs to be ratified with another vote
Not necessarily. The TSC has, for quite some time, been operating with a bias towards resolving issues in GitHub through natural discussion as opposed to votes, and there's nothing in the guidelines saying that past decisions cannot be revisited. Forcing a vote is possible, but I maintain that it is unnecessary, but given the objections you have raised the item is on the TSC agenda to be discussed.
That said, discussion on the matter is best directed to the pending PR. Standard practice... if there are objections to the change, raise them there and we can discuss. There's no reason whatsoever that I can see to rush this change even if it does land.
Reacted by Anna HenningsenAm I?
Yes. Remember I didn't push for the original change in policy, I'm largely indifferent.
However, I do care about following proper procedure. I also care about not wasting time rehashing old arguments (which is what we are doing now - fail!)
The TSC has [..] been operating with a bias towards resolving issues in GitHub through natural discussion as opposed to votes [..] there's nothing in the guidelines saying that past decisions cannot be revisited
I'm aware of that, I'm one of the people who instigated it. I was on the original CTC/TSC, remember?
If you think it's a legal interpretation of the current charter that ballots can be set aside after some time, then I suggest making it explicit that they are:
- binding,
- don't expire, and
- can only be subsumed by another ballot
Otherwise there's simply too much room for arbitrariness.
From what I understand, the decision of the CTC was specifically to drop support for Windows XP and Vista, not to set a policy about explicitly preventing the
node.exefrom running on EOL Windows versions.Reacted by Anna HenningsenOn V8 Currency: nothing to report.
It's been a few years but that's not how I remember it. The immediate result was blocking off XP and Vista but the wider discussion was about security and support.
XP was already documented as unsupported at the time but that didn't stop the influx of bug reports. People kept pushing for their pet bug. nodejs/node#3804 has some good examples.
XP at least had a large installed user base going for it, not something you can say about Windows 7, but in the end that argument didn't win the day either.
For strategic initiatives... now that OpenSSL 3 alpha1 is out, there is a discussion starting around how to start making the transition. It is, unfortunately, non-trivial, so it might make sense to include it as a strategic initiative to track progress.
@bnoordhuis @targos @cjihrig ... To avoid derailing the TSC agenda discussion any further, let's please move any further discussion of nodejs/node#33108 and the corresponding issue to those GitHub threads.
Not sure if I'll be able to join tomorrow, so here are my thoughts on current issues:
- Dispute of "block running on EOL Windows versions #31954" - Alternative Suggestion #33034
- src,win: Replacement of unsupported versions of Windows runtime exit #33108
I don't object to allow Node.js to run on older Windows versions. While on other operating sysmtes Node.js might not run on unsupported versions (due to incompatible libc or OS ABI), Windows is the only OS we explicitly prevent running. I think we should follow the same behavior we have on other OSs (if it doesn't work, it doesn't work, otherwise users can use it but if they find bug fixes that only affect unsupported platform versions, those bug fixes can be closed as
wontfix).- process: Throw exception on --unhandled-rejections=default #33021
I summed up some of my thoughts on nodejs/node#33021 (comment) and as of right now I still stand by nodejs/node#33021 (comment), but I still think we should take a survey before making any decisions on this issue.
- http: align with stream.Writable #31818
I summed up my understanding of the error handling changes on nodejs/node#31818 (comment) and based on that, I'm in favor of moving the PR forward since it doesn't prevent applications from terminating on errors raised by OutgoingMessage. If I missed something on the summary please let me know.
@benjamingr yes, thanks, obviously dropped the last number.
Time
UTC Wed 29-Apr-2020 14:00 (02:00 PM):
Or in your local time:
Links
Agenda
Extracted from tsc-agenda labelled issues and pull requests from the nodejs org prior to the meeting.
nodejs/node
nodejs/TSC
Invited
Observers/Guests
Notes
The agenda comes from issues labelled with
tsc-agendaacross 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.
Invitees
Please use the following emoji reactions in this post to indicate your
availability.