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 2024-08-21 #1607

Closed
mhdawson opened this issue Aug 19, 2024 · 7 comments
Closed

Node.js Technical Steering Committee (TSC) Meeting 2024-08-21 #1607

mhdawson opened this issue Aug 19, 2024 · 7 comments
Assignees

Comments

@mhdawson
Copy link
Member

Time

UTC Wed 21-Aug-2024 15:00 (03:00 PM):

Timezone Date/Time
US / Pacific Wed 21-Aug-2024 08:00 (08:00 AM)
US / Mountain Wed 21-Aug-2024 09:00 (09:00 AM)
US / Central Wed 21-Aug-2024 10:00 (10:00 AM)
US / Eastern Wed 21-Aug-2024 11:00 (11:00 AM)
EU / Western Wed 21-Aug-2024 16:00 (04:00 PM)
EU / Central Wed 21-Aug-2024 17:00 (05:00 PM)
EU / Eastern Wed 21-Aug-2024 18:00 (06:00 PM)
Moscow Wed 21-Aug-2024 18:00 (06:00 PM)
Chennai Wed 21-Aug-2024 20:30 (08:30 PM)
Hangzhou Wed 21-Aug-2024 23:00 (11:00 PM)
Tokyo Thu 22-Aug-2024 00:00 (12:00 AM)
Sydney Thu 22-Aug-2024 01:00 (01: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

  • lib: Symbol.dispose should be enabled with experimental flag #54329

nodejs/admin

  • Conversion to Enterprise account #905

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.


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 Aug 19, 2024
@benjamingr
Copy link
Member

Regarding: lib: Symbol.dispose should be enabled with experimental flag nodejs/node#54329

The ask is more around nodejs/node#54330 - i.e. I don't think we want to add an experimental warning to Symbol.dispose (though if people will all think otherwise I'll concede) but I think we should decide (as the TSC) that new experimental API implementations that affect globals/standards should have TSC consensus to land.

So the ask here is:

  • In the future when someone adds a new API that is either a web standard (e.g. fetch) or a JS API with polyfills (even minimal ones like Symbol.dispose) it would need TSC approval to land.
  • To be clear: TSC approval in this case means "lazy TSC consensus" (the TSC gets pinged).
  • In order to land a feature without TSC consensus - you need a compile time flag.

@ShogunPanda
Copy link
Contributor

If there is any chance, can we please briefly discuss nodejs/node#54404?

@aduh95
Copy link
Contributor

aduh95 commented Aug 21, 2024

  • In the future when someone adds a new API that is either a web standard (e.g. fetch) or a JS API with polyfills (even minimal ones like Symbol.dispose) it would need TSC approval to land.

@benjamingr The problem with that point would be that it's going to hard to automate/enforce – also, I'm very much in favor to try to fit into the existing processes rather than add another one.
My counter proposal would be that adding an API to a global object[^1] should be de facto semver-major (for which the automation enforces having at least two TSC approvals), and a TSC motion can decide it can be treated as semver-minor (so it gets discussed/mentioned in a TSC meeting).

[1]: Not sure if process should be a special-case, since it's a Node.js-only global.

@legendecas
Copy link
Member

legendecas commented Aug 21, 2024

Distinctions regarding different experimental global/standards here are that:

  1. Standards adding a new global implemented in dependencies (e.g. JS globals in V8):
    1. global polyfills made in Node.js core will need to be removed once the dependencies ship them without a flag.
    2. breaking changes made in dependencies will diverge from the polyfill in Node.js core, and the decisions are taken outside the space of Node.js.
    3. dependencies may not be upgraded in semver-major versions of Node.js, due to ABI compatibility and maintenance cost.
  2. Standards adding a new global implemented in Node.js core (e.g. Web streams):
    1. decisions are taken in the space of Node.js, it may be trivial to backport the changes. But we can also apply semver-major to avoid breaking.

I'd suggest as a minimal rule, for standards implemented in deps, apply the same policy in deps on the polyfill in Node.js, e.g. V8 requires new JS globals to be hidden behind cli flags. And enable the flag by default once all the standard test suites are passed. This reduces the discrepencies on unfinished features.

Additionally, +1 to @aduh95's suggestion, semver-major on adding a new experimental global can fit into the existing processes on TSC approval and backports.

@benjamingr
Copy link
Member

Additionally, +1 to @aduh95's suggestion, semver-major on adding a new experimental global can fit into the existing processes on TSC approval and backports.

I'm fine with that, I just think it's not generic enough to have a policy that doesn't involve the TSC since it's a cross-cutting cross-body concern so we should (briefly) discuss it.

If there is any chance, can we please briefly discuss nodejs/node#54404?

SGTM (to discuss)

@benjamingr
Copy link
Member

joining in 5m (kids/summer related)

@mhdawson
Copy link
Member Author

PR for minutes - #1608

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

5 participants