doc: add minutes for meeting Jan 24 2024 #1496
Conversation
Signed-off-by: Michael Dawson <midawson@redhat.com>
Signed-off-by: Michael Dawson <midawson@redhat.com>
Co-authored-by: Antoine du Hamel <duhamelantoine1995@gmail.com>
Co-authored-by: Antoine du Hamel <duhamelantoine1995@gmail.com>
| * 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 |
There was a problem hiding this comment.
@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.
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.
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.
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.
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.
Thanks @mhdawson, exactly that.
No description provided.