GeezerVison is showing github.com — Node.js Technical Steering Committee (TSC) Meeting 2025-01-22 · Issue #1676 · nodejs/TSC
Node.js Technical Steering Committee (TSC) Meeting 2025-01-22 #1676DescriptionTime
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:
Links
Agenda
Extracted from tsc-agenda labelled issues and pull requests from the nodejs org prior to the meeting.
nodejs/node
- doc: change smartos support type to experimental #56220
- test: improve zlib tests #55716
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
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
Reacted by Rafael Gonzaga Activitymhdawson commented on Jan 20, 2025 Going to add #1678 for awareness as well mcollina commented on Jan 21, 2025 SponsorMember More actions I think the plan for this meeting is to invite the folks at @nodejs/platform-smartos to discuss.
Can everyone interested join this? Reacted by Joshua M. Clulow and Brianna Madeline jasnell commented on Jan 22, 2025 Can we please be sure to discuss nodejs/node#56671 and the general strategy around node:test usage 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 commented on Jan 22, 2025
I think the plan for this meeting is to invite the folks at @nodejs/platform-smartos to discuss. Can everyone interested join this?
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 commented on Jan 22, 2025
Can we please be sure to discuss nodejs/node#56671 and the general strategy around node:test usage 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.
@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 commented on Jan 22, 2025
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 feel that these are not very well related to the use of node:test or not. Just yesterday I was banging my head against test/parallel/test-node-output-errors.mjs - even though it is written with node: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... Reacted by Luigi Pinca and Michaël Zasso jasnell commented on Jan 22, 2025 I personally don't care if it's node:test or 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 commented on Jan 22, 2025
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.
FWIW I would agree that these should not land, to quote myself from nodejs/node#56027 (comment)
I think maybe a good measure about this might be: only the people maintaining what the test is testing get to choose what format the test should be written in, and forbid test-only changes from PRs that don't simultaneously change the features that the test is testing (unless they obviously had many commits in said feature or they reach consensus about this if there are multiple people maintaining said feature).
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. Reacted by Luigi Pinca and Michaël Zasso joyeecheung commented on Jan 22, 2025
I personally don't care if it's node:test or 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.
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. Reacted by Luigi Pinca and Michaël Zasso lpinca commented on Jan 22, 2025
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.
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:test might make sense (I would prefer to split it into individual tests though).
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.
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)
After months of discussions (nodejs/node#54796, here, several refactoring PRs) I still can't see any good/solid reason in favor of using node:test for existing (and new) tests. All the reasons listed so far by proponents (3de15b8, nodejs/node#56027 (comment)) are weak (sometimes invalid) and don't even remotely outweigh the disadvantages.
To name a few
Reacted by Michaël Zasso and Beth Griggs jasnell commented on 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.
I do not remember of ever blocking a first time contributor PR over this
That literally happened yesterday in nodejs/node#56671 but ok I suppose.
All the PRs I am blocking do not improve anything, they are just making things worse than they are.
Opinions can reasonably differ. lpinca commented on Jan 22, 2025
That literally happened yesterday in nodejs/node#56671 but ok I suppose.
Not a first time contributor, find another example. aduh95 commented on Jan 22, 2025
That literally happened yesterday in nodejs/node#56671 but ok I suppose.
Not a first time contributor, find another example.
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 a First-time contributor badge at the time, which is probably the source of the confusion here. lpinca commented on 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 commented on Jan 22, 2025 @lpinca :
Not a first time contributor, find another example.
@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 commented on Jan 22, 2025 @jasnell no offence but so is this
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.
Again, find other examples where this is true. mhdawson commented on Jan 22, 2025
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|