Repository navigation
Node.js Technical Steering Committee (TSC) Meeting 2025-01-22 #1676
Description
Time
UTC Wed 22-Jan-2025 16:00 (04:00 PM):
| Timezone | Date/Time |
|---|---|
| US / Pacific | Wed 22-Jan-2025 08:00 (08:00 AM) |
| US / Mountain | Wed 22-Jan-2025 09:00 (09:00 AM) |
| US / Central | Wed 22-Jan-2025 10:00 (10:00 AM) |
| US / Eastern | Wed 22-Jan-2025 11:00 (11:00 AM) |
| EU / Western | Wed 22-Jan-2025 16:00 (04:00 PM) |
| EU / Central | Wed 22-Jan-2025 17:00 (05:00 PM) |
| EU / Eastern | Wed 22-Jan-2025 18:00 (06:00 PM) |
| Moscow | Wed 22-Jan-2025 19:00 (07:00 PM) |
| Chennai | Wed 22-Jan-2025 21:30 (09:30 PM) |
| Hangzhou | Thu 23-Jan-2025 00:00 (12:00 AM) |
| Tokyo | Thu 23-Jan-2025 01:00 (01:00 AM) |
| Sydney | Thu 23-Jan-2025 03:00 (03:00 AM) |
Or in your local time:
- https://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+Technical%20Steering%20Committee%20(TSC)+Meeting+2025-01-22&iso=20250122T1600
- or https://www.wolframalpha.com/input/?i=04PM+UTC%2C+Jan+22%2C+2025+in+local+time
Links
- Minutes Google Doc: https://docs.google.com/document/d/1UzJTZxA64DbrJk9ktlEdHi8mL7fthKTTes6qnNmiofY/edit
Agenda
Extracted from tsc-agenda labelled issues and pull requests from the nodejs org prior to the meeting.
nodejs/node
nodejs/TSC
- Status of smartOS support and what future holds #1663
- Clarify the Charter so that contractors are explicity counted as affialiated #1650
- Let's talk about the CI situation #1614
Invited
- Antoine du Hamel @aduh95 (voting member)
- Yagiz Nizipli @anonrig (voting member)
- Benjamin Gruenbaum @benjamingr (voting member)
- Ruben Bridgewater @BridgeAR (voting member)
- Gireesh Punathil @gireeshpunathil (voting member)
- James Snell @jasnell (voting member)
- Joyee Cheung @joyeecheung (voting member)
- Chengzhong Wu @legendecas (voting member)
- Marco Ippolito @marco-ippolito (voting member)
- Matteo Collina @mcollina (voting member)
- Michael Dawson @mhdawson (voting member)
- Rafael Gonzaga @RafaelGSS (voting member)
- Richard Lau @richardlau (voting member)
- Robert Nagy @ronag (voting member)
- Ruy Adorno @ruyadorno (voting member)
- Paolo Insogna @ShogunPanda (voting member)
- Michaël Zasso @targos (voting member)
- Tobias Nießen @tniessen (voting member)
- Anatoli Papirovski @apapirovski (regular member)
- Beth Griggs @BethGriggs (regular member)
- Ben Noordhuis @bnoordhuis (regular member)
- Colin Ihrig @cjihrig (regular member)
- Geoffrey Booth @GeoffreyBooth (regular member)
- Moshe Atlow @MoLow (regular member)
- Shelley Vohr @codebytere (regular member)
- Rich Trott @Trott (regular member)
- Joe Sepi @joesepi (Guest - Node.js CPC rep)
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
Activity
mhdawson commentedon Jan 20, 2025
Going to add #1678 for awareness as well
mcollina commentedon Jan 21, 2025
I think the plan for this meeting is to invite the folks at @nodejs/platform-smartos to discuss.
Can everyone interested join this?
jasnell commentedon Jan 22, 2025
Can we please be sure to discuss nodejs/node#56671 and the general strategy around
node:testusage in tests.@lpinca has taken to blocking many of these.... https://github.com/nodejs/node/pulls?q=sort%3Aupdated-desc+is%3Apr+is%3Aopen++%22test%3A+migrate+tests+to+use+node%3Atest%22+
My general opinion on it is: Our tests as a whole need (a) more structural consistency, (b) better structure with clear delineation between individual things being test, (c) A clear consistent style across the test suite, (d) more documentation about what is being tested for, what is being asserted, (e) more separation between internal API tests and public API surface tests, etc. I would rather we not end up in a case where we have more inconsistency between tests where some have a more defined structure and others have no structure at all, some have more documentation and others have no documentation at all, etc, and we're in a situation now where multiple contributors, including brand new contributors, are being blocked by a single individual over what appears to be mostly a disagreement over style.
anonrig commentedon Jan 22, 2025
I can't attend tomorrow due to doctors appointment, but I've tried to ping the team and all issues I've encountered/seen in the past 2 weeks. Most recent one by @joyeecheung: nodejs/node#56590 (comment)
anonrig commentedon Jan 22, 2025
@nodejs/tsc I can't attend tomorrow but I'd appreciate if you could discuss nodejs/node#56027. It's not blocked by anyone, and can be merged as it is, but due to the relation of the topic agenda, it would be in benefit of the project to talk about this one last time before merging it.
joyeecheung commentedon Jan 22, 2025
I feel that these are not very well related to the use of
node:testor not. Just yesterday I was banging my head againsttest/parallel/test-node-output-errors.mjs- even though it is written withnode:test, I don't find it any better in these regards that help me understand it when I changed the module loader internals in a way that broke the test...jasnell commentedon Jan 22, 2025
I personally don't care if it's
node:testor not. We need to improve our tests and we need to do so consistently. I'd like a blessed approach not an ad hoc approach that just leads to more inconsistency.joyeecheung commentedon Jan 22, 2025
FWIW I would agree that these should not land, to quote myself from nodejs/node#56027 (comment)
Style-only changes, in general, are counter-productive for our workflow. For example I am in the process of backporting
require(esm)to v20.x, and it has many dependency commits. The amount of conflicts already makes it hard enough that I am on the verge of giving up and I only have not given up because many package maintainers count on this to be able to drop dual shipping this April. But if I had to struggle with mass conflicts in the middle that were only introduced for stylistic preferences, it would be annoying enough that I would not do it.joyeecheung commentedon Jan 22, 2025
I feel that in that case, we should focus on the guide lines that actually help improve the tests e.g. writing comments, splitting tests properly, and leave node:test out of the equation. Personally I find many of the existing tests that use node:test are harder to understand due to the fact that they squeeze way too many test cases in one file, or have only very few words that don't even form a sentence as descriptions, like the one mentioned and many other test/es-module. I doubt blessing node:test makes any difference if the existing tests that use it are already not great in terms of readability, or worse than many tests without it that are smaller and have more comments.
lpinca commentedon Jan 22, 2025
This was already discussed in nodejs/node#54796, and I think the wast majority of our tests are good as is. I agree with (d) and it can be solved it comments. (c) is already in place, inconsistencies are being created by the useless refactors. I also partially agree with (b) and if the a test contains multiple subtests, using
node:testmight make sense (I would prefer to split it into individual tests though).I do not remember of ever blocking a first time contributor PR over this. I have actually refrained of doing so in some cases (nodejs/node#55747 (comment)) and it is not about style, it is about adding value. All the PRs I am blocking do not improve anything, they are just making things worse than they are.
Quoting myself from nodejs/node#56027 (comment)
To name a few
jasnell commentedon Jan 22, 2025
Very well. I'll drop it. I completely disagree but I can see no progress will be made and it'll be pointless to try.
That literally happened yesterday in nodejs/node#56671 but ok I suppose.
Opinions can reasonably differ.
lpinca commentedon Jan 22, 2025
Not a first time contributor, find another example.
aduh95 commentedon Jan 22, 2025
tbf, at the time of the block (08:12 AM UTC) that user didn't have any commit on
main– nodejs/node@23c2d33 landed later on the same day (17:16 UTC) – so it's possible that GH UI was showing aFirst-time contributorbadge at the time, which is probably the source of the confusion here.lpinca commentedon Jan 22, 2025
The commit-queue label was added to nodejs/node#56659 on jan 19, 2025 6:39 PM GMT +1, but ok.
jasnell commentedon Jan 22, 2025
@lpinca :
@lpinca ... I'm sorry but this dismissive and pedantic attitude is toxic and unwarranted. The contributor IS a first-time contributor. The fact that they happen to have had two PRs in the pipeline at the same time does not change that fact. They are a brand new contributor seeking to make small initial contributions so that they can learn the process of how contributions work, how code review works, etc before seeking to make more substantial contributions later. So far the experience has been... less than encouraging... for them and this kind of response is unfriendly and unwelcoming.
lpinca commentedon Jan 22, 2025
@jasnell no offence but so is this
Again, find other examples where this is true.
mhdawson commentedon Jan 22, 2025
PR for minutes - #1679