-
Notifications
You must be signed in to change notification settings - Fork 134
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
Comments
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 |
Promises, we should resolve
|
QUIC ... no significant updates. Working on separating out non-QUIC specific bits from the PR to land separately. |
For strategic initiatives, just also want to make sure folks see this: #853 ... not something that needs to be on the agenda tho. |
|
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:
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
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.
My position on this remains the same. It's something that should move forward as semver-major with coordination with framework developers. |
You're misrepresenting what I said, don't do that. The facts as I see them:
@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:
|
It's also worth pointing out a recent comment by @bzoz (one of the top Windows maintainers for both Node and libuv):
|
Am I?
And this...
... 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.
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. |
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!)
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:
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 |
On 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:
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
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.
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. |
PR for minutes: #858 (Edited to fix link) |
@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-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.
The text was updated successfully, but these errors were encountered: