-
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
doc: add minutes for meeting Jan 24 2024 #1496
Merged
Merged
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,116 @@ | ||
| # Node.js Technical Steering Committee (TSC) Meeting 2024-01-24 | ||
|
|
||
| ## Links | ||
|
|
||
| * **Recording**: <https://www.youtube.com/watch?v=KzBhROQFcDE> | ||
| * seems like the recording dropped at 34mins, not sure why, unfortunately because | ||
| there was a lot of good discussion | ||
| * **GitHub Issue**: <https://github.com/nodejs/TSC/issues/1495> | ||
|
|
||
| ## Present | ||
|
|
||
| * Antoine du Hamel @aduh95 (voting member) | ||
| * Geoffrey Booth @GeoffreyBooth (voting member) | ||
| * James Snell @jasnell (voting member) | ||
| * Joyee Cheung @joyeecheung (voting member) | ||
| * Chengzhong Wu @legendecas (voting member) | ||
| * Michael Dawson @mhdawson (voting member) | ||
| * Moshe Atlow @MoLow (voting member) | ||
| * Richard Lau @richardlau (voting member) | ||
| * Ruy Adorno @ruyadorno (voting member) | ||
| * Myles Borins @MylesBorins (regular member) | ||
|
|
||
| ## Agenda | ||
|
|
||
| ### Announcements | ||
|
|
||
| * Antoine - 2 successful collaborator nominations - lemire and zcbenz | ||
|
|
||
| ### CPC and Board Meeting Updates | ||
|
|
||
| *Extracted from **tsc-agenda** labeled issues and pull requests from the **nodejs org** prior to the meeting. | ||
|
|
||
| ### nodejs/node | ||
|
|
||
| * enable corepack by default [#50963](https://github.com/nodejs/node/issues/50963) | ||
| * Myles, speaking as fellow collaborator | ||
| * Believe questions are being framed incorrectly | ||
| * Question is about enabling yarn, pump and having them just work | ||
| * When looking at what Node.js is shipping only 10% is coming from supported Node.js | ||
| versions, lots still come from older versions | ||
| * yarn and pnpm have large enough downloads, | ||
| * npm don’t want to support/integrate with corepack as it does not fit with view of how | ||
| package managers should be integrated | ||
| * corepack was started due to context that limited willingness to add yarn/pnpm to Node.js, | ||
| but extended beyond that. | ||
| * believe we should make yarn and pnpm just work, but that does not necessarily mean | ||
| corepack | ||
| * should define governance for supporting clients | ||
| * Michael | ||
| * Need to factor in work on the project to support any particular solution | ||
| * Richard, if npm was not currently bundled we probably would not bundle, so if we define | ||
| criteria for bundling, npm would likely not meet them. Situation is not equitable, but we have | ||
| historical baggage and those constrain what is reasonable. | ||
| * Michael a bit of a response | ||
| * Geoffrey | ||
| * Sounds great in abstract that we let yarn/pnpm run without doing anything but at what | ||
| cost? | ||
| * It’s finding an option with the right cost/value balance | ||
| * Myles | ||
| * Question, is are we going to ship these and take on responsibility for the clients | ||
| * Corepack tries to take those on, but does it actually let us say “no” to us taking on | ||
| responsibility | ||
| * James, do believe it’s an important distinction that it does not bundle the clients that should | ||
| not be lost. Exploring different options does make sense. | ||
| * Myles yarn, pnpm just working can lead people to thinking its the same, which is a concern. | ||
| * Myles in support of finding equitable environment | ||
| * Richard - when installing things, having up front questions; that is how npx works; | ||
| corepack like npx downloads software that we are not responsible for. | ||
| * Geoffrey, somebody needs to be champion to finding consensus. Issues and PRs need to | ||
| be opened to capture goals, etc. | ||
| * Ruy, in the first discussion back in 2020, there were lots of questions back them, and | ||
| agreement was that we should run an experiment. | ||
| * Geoffrey, just because we skipped finding consensus earlier, does not mean that we have | ||
| to accept implementation. | ||
| * Richard, unfair to characterize as non-consensus | ||
| * Geoffrey, consensus as experiment is quite different than implementation | ||
| * Michael, Ruys point I think is that it should not be a surprise that there are still divergent | ||
| opinions because those were raised and what was agreed was only an experiment. | ||
| * Geoffrey, will post comment that TSC members who were present, best way to move | ||
| forward is to define goals, and work on agreement on those. Getting those PR’d into some | ||
| Node.js doc even if that requires a TSC vote is a prereq. | ||
|
|
||
| * lib: promote process.binding/_tickCallback to runtime deprecation [#50687](https://github.com/nodejs/node/pull/50687) | ||
| * skipped for this week | ||
|
|
||
| * lib: rewrite AsyncLocalStorage without async_hooks [#48528](https://github.com/nodejs/node/pull/48528) | ||
| * @lgendecas will check with Stephen if this can be removed from agenda, there was progress | ||
| on the V8 front, so it might be unblocked. | ||
|
|
||
| ### nodejs/admin | ||
|
|
||
| * Redesign of Node.js Website [#818](https://github.com/nodejs/admin/issues/818) | ||
| * removed from agenda, as presentation was made last week. | ||
|
|
||
| * Events / Collaborator Summits for 2024 [#814](https://github.com/nodejs/admin/issues/814) | ||
| * Have confirmation that they can host the collaborator summit, took a while due to estimate of | ||
| attendance. Have space for 30-35 people on April 3-4. | ||
| * Question is if there is enough time to get people to show up to event. Maybe we should do a | ||
| poll, if we get enough people then we can move forward, otherwise we can move to some | ||
| time later in the year. | ||
| * Michael, is it possible to have Node.js track? | ||
| * Joyee, not sure but should run survey in parallel | ||
| * Joyee, people ok with the plan. | ||
| * Have space for 30-35 people on April 3-4, in London | ||
| * run poll to see how many people are planning to attend the summit | ||
| * wait for a week to see how many people are planning to go. | ||
| * If number is enough for critical mass, if not then we should plan to delay. | ||
| * Ruy, propose hosting collaborator summit collocated with conference in Colombia, end of October this year | ||
|
|
||
| ## Strategic Initiatives | ||
|
|
||
| ## Upcoming Meetings | ||
|
|
||
| * **Node.js Project Calendar**: <https://nodejs.org/calendar> | ||
|
|
||
| Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. | ||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@richardlau @MylesBorins @mhdawson I was unable to attend the meeting but the part I don't understand is with regards to @mcollina 's point from last week.
Currently there is exactly one package manager hosting a public registry (with a few mirrors), all other package managers are npm clients that talk to the npm registry. npm can (but doesn't) break other clients but that's out of kindness.
The situation isn't equitable because exactly one client is footing the server bill, not because one client is bundled - and I suspect that had we made the choice today npm would still be bundled or we would ship our own registry (which would incur high costs and would require the project to foot the bill instead of GitHub).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's obviously more than one public registry, npm is "just" the most popular one especially for the JS ecosystem. Let's not start discussing npm intents, whether it's kindness or whatever, we don't know that (unless you do?), and I don't think it's relevant. FWIW I agree with Richard, if npm wasn't bundled today, we would probably not bundle it; my guess is that npm themselves would distribute
node– and that would probably work better for everyone.(You probably already know that, this PR is about keeping notes of what folks say, so this discussion should not block the PR from landing)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My point was more that if we were to define criteria today for bundling a package manager with Node.js it is likely that npm wouldn't meet that criteria (see for example, historic tension around npm's lack of long-term support) (FTR I have no idea if any of the other package managers would meet such criteria either). Personally I do not consider that a reason by itself to suggest not bundling npm now as it would be too disruptive to the ecosystem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed that npm has a release management that is at odds with the one with follow, and it would likely not meet that bar. Specifically around the fact that they use September as the month to ship their major, because we go LTS in October.
@benjamingr can you refer to what I said last week that was not clear?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My 2 cents of clarifying what @mcollina said. It is that because the npm client comes from and is supported by GitHub who hosts the registry, it will always have the distinction of being the "official" client in terms of the provider of the registry (GitHub). Nothing that the node.js project does will change the benefits that distinction brings to the npm client. For example if something in the registry does not work with the npm client, then GitHub should work to fix that either in the registry or the client. If something does not work with some of the other package managers then they might consider it a problem in the client and not be interested in making changes in the registry even if that means it will be a lot of work for the client to fix the issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @mhdawson, exactly that.