Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Node.js Technical Steering Committee (TSC) Meeting 2020-04-29 #856

Closed
mhdawson opened this issue Apr 27, 2020 · 20 comments
Closed

Node.js Technical Steering Committee (TSC) Meeting 2020-04-29 #856

mhdawson opened this issue Apr 27, 2020 · 20 comments
Assignees

Comments

@mhdawson
Copy link
Member

mhdawson commented Apr 27, 2020

Time

UTC Wed 29-Apr-2020 14:00 (02:00 PM):

Timezone Date/Time
US / Pacific Wed 29-Apr-2020 07:00 (07:00 AM)
US / Mountain Wed 29-Apr-2020 08:00 (08:00 AM)
US / Central Wed 29-Apr-2020 09:00 (09:00 AM)
US / Eastern Wed 29-Apr-2020 10:00 (10:00 AM)
London Wed 29-Apr-2020 15:00 (03:00 PM)
Amsterdam Wed 29-Apr-2020 16:00 (04:00 PM)
Moscow Wed 29-Apr-2020 17:00 (05:00 PM)
Chennai Wed 29-Apr-2020 19:30 (07:30 PM)
Hangzhou Wed 29-Apr-2020 22:00 (10:00 PM)
Tokyo Wed 29-Apr-2020 23:00 (11:00 PM)
Sydney Thu 30-Apr-2020 00:00 (12:00 AM)

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

  • Dispute of "block running on EOL Windows versions #31954" - Alternative Suggestion #33034
  • process: Throw exception on --unhandled-rejections=default #33021
  • http: align with stream.Writable #31818
  • src,win: Replacement of unsupported versions of Windows runtime exit #33108

nodejs/TSC

  • Nominations for TSC Chair - Open April 16 through 30th 2020 #851
  • Node.js future directions - any interest in online or in person summit? #797

Invited

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.


Invitees

Please use the following emoji reactions in this post to indicate your
availability.

  • 👍 - Attending
  • 👎 - Not attending
  • 😕 - Not sure yet
@mhdawson mhdawson self-assigned this Apr 27, 2020
@Trott
Copy link
Member

Trott commented Apr 28, 2020

Moderation Team report: Some internal discussions, but no Moderation actions. @nodejs/moderation @nodejs/tsc @nodejs/community-committee

@Trott
Copy link
Member

Trott commented Apr 28, 2020

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 @mhdawson

@mcollina
Copy link
Member

Promises, we should resolve

process: Throw exception on --unhandled-rejections=default #33021

@jasnell
Copy link
Member

jasnell commented Apr 28, 2020

QUIC ... no significant updates. Working on separating out non-QUIC specific bits from the PR to land separately.

@jasnell
Copy link
Member

jasnell commented Apr 28, 2020

For strategic initiatives, just also want to make sure folks see this: #853 ... not something that needs to be on the agenda tho.

@mhdawson
Copy link
Member Author

  • Build resources
    • Nothing to report this week.

@jasnell
Copy link
Member

jasnell commented Apr 28, 2020

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 one and @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.

@bnoordhuis
Copy link
Member

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:

  1. The CTC set the current policy after a lot of deliberation and a show of hands.

  2. Some people now want to backtrack on that.

  3. 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:

  1. Why backtrack? There are good reasons for the current policy.

  2. Why whitelist Windows when we do the same thing on macOS?

@cjihrig
Copy link
Contributor

cjihrig commented Apr 28, 2020

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.

@jasnell
Copy link
Member

jasnell commented Apr 28, 2020

You're misrepresenting what I said...

Am I?

nodejs/node#33034 (comment)

...I'm closing this as a wontfix.

nodejs/node#33034 (comment)

...The reason I closed this so quickly is that trying to backtrack on it just wastes everyone's time

nodejs/node#33034 (comment)

...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.

@bnoordhuis
Copy link
Member

Am 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.

@targos
Copy link
Member

targos commented Apr 28, 2020

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.exe from running on EOL Windows versions.

@targos
Copy link
Member

targos commented Apr 28, 2020

On V8 Currency: nothing to report.

@bnoordhuis
Copy link
Member

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.

@jasnell
Copy link
Member

jasnell commented Apr 28, 2020

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.

@jasnell
Copy link
Member

jasnell commented Apr 28, 2020

@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.

@mmarchini
Copy link
Contributor

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.

@mhdawson
Copy link
Member Author

mhdawson commented Apr 29, 2020

PR for minutes: #858 (Edited to fix link)

@benjamingr
Copy link
Member

@mhdawson did you mean to link to #858 ?

@Trott Trott closed this as completed Apr 29, 2020
@mhdawson
Copy link
Member Author

@benjamingr yes, thanks, obviously dropped the last number.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants