Repository navigation
Node.js Technical Steering Committee (TSC) Meeting 2024-06-12 #1575
Description
Activity
We can probably remove these from the agenda, I had tagged them just for awareness. (Unless anyone else involved in these threads wants to discuss them.)
- module: allow module.register from workers #53200
- src: make
--env-filereturn warning when not found #53177 - Module customization hooks and worker threads #1566
Reacted by Benjamin GruenbaumWe only had 5 people make it to the meeting today so we cancelled. See everybody next week.
Reacted by Benjamin Gruenbaum@GeoffreyBooth I think unless you've had suggestions otherwise, since you tagged those items for the agenda you should be ok taking off the tag so they don't show up on the agenda for next week.
We only had 5 people make it to the meeting today so we cancelled. See everybody next week.
Sorry, ran late with the kids due to the holiday here, not that 6 people instead of 5 would've necessarily fixed things :]
I would’ve joined late too but it’s fine. @mhdawson I’d already untagged them.
Maybe a meta-issue we want to discuss is whether there should be a team whose focus is on CLI stuff, that can be responsible for
--env-fileand related things. Then issues related to those features would have a place to be discussed besides the TSC, to avoid every disagreement rising to the TSC level.Along those lines, there hasn’t been a loaders team for quite some time now; I’m the only one consistently attending the meetings anymore. I have no one to ask for guidance from for loaders issues other than the TSC.
Reacted by Benjamin GruenbaumIn terms of the --env-file would the @nodejs/tooling team make sense?
Reacted by Ruy Adorno and Geoffrey BoothIn terms of the --env-file would the @nodejs/tooling team make sense?
--env-fileis currently blocked, therefore requires voting to be resolved. assigning a team to the CLI makes sense in the long term, but doesn't resolve the conflict we're facing right now.--env-fileis currently blocked, therefore requires voting to be resolved. assigning a team to the CLI makes sense in the long term, but doesn’t resolve the conflict we’re facing right now.The idea is that if there’s a team responsible for the feature, that team could have periodic meetings and talk through disagreements in an attempt to find a resolution. The recent loaders meeting with me, Paolo and Gabriel was very productive and we resolved all open questions (at least, open between the three of us) about how to handle the off-thread hooks/worker threads issue. Perhaps if the tooling team held a similar meeting where all interested parties could discuss this issue, and the group had a full hour on that one topic, a similar resolution could be achieved.
The idea is that if there’s a team responsible for the feature, that team could have periodic meetings and talk through disagreements in an attempt to find a resolution. The recent loaders meeting with me, Paolo and Gabriel was very productive and we resolved all open questions (at least, open between the three of us) about how to handle the off-thread hooks/worker threads issue. Perhaps if the tooling team held a similar meeting where all interested parties could discuss this issue, and the group had a full hour on that one topic, a similar resolution could be achieved.
@GeoffreyBooth the pull request is blocked for more than 17 days. we don't need more discussions. we need a resolution.
- added a commit that references this issue
on Jun 14, 2024 @GeoffreyBooth the pull request is blocked for more than 17 days. we don’t need more discussions. we need a resolution.
I assume you’re referring to nodejs/node#53177? What about nodejs/node#53060, which was blocked first? The only justification you gave was
I’m -1 on this change. It makes the existing implementation harder to maintain for almost no gain. We should not throw on env-file instead.
If your only concern was the maintainability of the implementation, that sounds like something that could have been resolved by discussion and compromise. It seems like you actually just prefer an alternate behavior, which is fine, but then the question is why we can’t just have both via two flags, even if we flip the default (like if
--env-filewarns and--env-file-requiredthrows). I’d guess that your position is that the complexity of two flags is not worth the maintenance cost, but if several collaborators are telling us that they want both behaviors, perhaps it’s not really “almost no gain”?Even though there are a lot of comments on these PRs I don’t really see discussion like what often happens in team meetings. I don’t see much engagement with @BoscoDomingo to discuss ideas for how to achieve the use case he’s trying to support while still respecting your priorities. I don’t think this needs to be a situation where it’s zero-sum and we either choose one option or another, and one side has to win and another has to lose; there might be a compromise here, but I don’t see much attempt at reaching one. At the very least, a meeting where everyone can be heard would be a good start.
Reacted by Bosco DomingoI’ve done plenty of meetings to
resolve technical issues, and those are often needed to resolve disagreements and find a common ground. However, there is also the way of not disagreeing in the first place. In other terms, what battles to fight and what battles not to fight.There are also deep technical arguments where a debate is useful to understand differences. Having said that, these long debates could wear people out. I highly recommend we avoid them if possible. Voting is often better.
I’ve done plenty of meetings to
resolve technical issues, and those are often needed to resolve disagreements and find a common ground. However, there is also the way of not disagreeing in the first place. In other terms, what battles to fight and what battles not to fight.There are also deep technical arguments where a debate is useful to understand differences. Having said that, these long debates could wear people out. I highly recommend we avoid them if possible. Voting is often better.
@mcollina agree on keeping meetings to a minimum. We've probably got enough at our dayjobs, plus scheduling it in the first place could be a nightmare.
However, @GeoffreyBooth does bring up a great point with flipping my PR upside down, and making
--env-file-requireda thing. It's the perfect middle ground, where the default warns instead of throwing as @anonrig and others suggest, but we still keep the existing behaviour for those who prefer that. IMO we kill two birds with one stone, and appease everyone.- added a commit that references this issue
on Jun 17, 2024
Time
UTC Wed 12-Jun-2024 15:00 (03:00 PM):
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
--env-filereturn warning when not found #53177nodejs/TSC
nodejs/admin
nodejs/next-10
Invited
Observers/Guests
Notes
The agenda comes from issues labelled with
tsc-agendaacross 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.