From ecdd88bfae91be52c1f8427c01b43a7b5e649d78 Mon Sep 17 00:00:00 2001 From: Ruy Adorno Date: Wed, 23 Jul 2025 15:09:37 -0400 Subject: [PATCH] doc: add minutes for meeting 23 Jul 2025 --- meetings/2025-07-23.md | 150 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 150 insertions(+) create mode 100644 meetings/2025-07-23.md diff --git a/meetings/2025-07-23.md b/meetings/2025-07-23.md new file mode 100644 index 00000000..315f1055 --- /dev/null +++ b/meetings/2025-07-23.md @@ -0,0 +1,150 @@ +# Node.js Technical Steering Committee (TSC) Meeting 2025-07-23 + +## Links + +* **Recording**: +* **GitHub Issue**: + +## Present + +* Antoine du Hamel @aduh95 (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) +* Michael Dawson @mhdawson (voting member) +* Filip Skokan @panva (voting member) +* Rafael Gonzaga @RafaelGSS (voting member) +* Darshan Sen @RaisinTen (voting member) +* Richard Lau @richardlau (voting member) +* Ruy Adorno @ruyadorno (voting member) + +## Agenda + +### Announcements + +* New collaborator: Aditi-1400 +* Survey for collaborator summit in October: + + +### Reminders + +* Remember to nominate people for the [contributor spotlight](https://github.com/nodejs/node/blob/main/doc/contributing/reconizing-contributors.md#bi-monthly-contributor-spotlight) + +### CPC and Board Meeting Updates + +* No update this week + +*Extracted from **tsc-agenda** labeled issues and pull requests from the **nodejs org** prior to +the meeting. + +### nodejs/Release + +* Proposal - Shift Node.js to Annual Major Releases and Shorten LTS Duration [#1113](https://github.com/nodejs/Release/issues/1113) + * TLDR from Rafael: strong support to move to an yearly release, making the deprecation window + shorter + * got feedback that 24mo of LTS seems too short for some enterprise + * Gireesh: we need to be aware that increasing the frequency of updates may increase the number + of issues companies face when updating major versions + * James: instead of making every major release a LTS we keep the odd vs even number + differentiation but we switch the cadence to a single major release every year + * Rafael: one issue with the odd-number releases is lack of adoption, not sure about the yearly + release + * James: it’s important to get the major / breaking-changes in the hands of users as early as + possible + * Marco: with the current schedule there are periods of time we have 4 concurrent release lines + to make security releases to and so forth + * Marco: maybe making backport more strict + * Michael: what’s the difference between making major releases LTS vs non-LTS (odd numbered) + * James: historically the reason for having this schedule is to try to cater to different + ecosystem users, big enterprise vs small companies vs modules authors / maintainers, we still + need to support all those audiences + * Filip: another big audience is CI, module authors want to be testing in latest / current to + make sure their libraries are still working, switching that model to a prerelease channel + does not have the same connotation + * Joyee: there's another audience which is users of tools that relies on node, like cli tools + that depends on node and they tend to use the current release line, we learn about them + whenever we break things + * James: typically that's the tool author that is making that decision to their end users, + regardless stability guarantee is a big distinction and these authors will not adopt + prerelease lines + * Rafael: some major releases have none or almost none breaking changes but the major release + happens more because of schedule + * James: that predictability is important to companies and enterprise + * Michael: going back to the conversation of the cost of having 4 different release lines to + maintain at a given time, what about the odd-versions never get security releases in order + to reduce the burden? + * James: that guarantees nobody ever adopts or uses the odd-versions + * James: overlapping LTS versions are important for companies that need that support guarantee + * Richard: one of the reasons we do semver-major releases is to bump up V8 versions, since any + V8 update is semver-major + * Richard: people expect that predictability, it’s very important to the enterprise world + * James: none of that is theoretical, this is all based on real world user feedback + * James: we probably need a couple of different proposals we can work through + * Filip: we need to take into account our own dependencies and their release schedules, openssl + is going to switch to a two-year LTS schedule, it would be a good exercise to overlap that + openssl calendar with ours and see how that aligns + +### nodejs/nodejs.org + +* Node.js Icon Standardization [#7880](https://github.com/nodejs/nodejs.org/issues/7880) + * Ruy: it looks like the OpenJS Foundation marketing team already followed up with the approvals + required, the ask is more for following up updating the logo and was also marked as + tsc-agenda for awareness + * Checklist of places that need to be updated in + +### nodejs/TSC + +* Interim TSC Election [#1763](https://github.com/nodejs/TSC/issues/1763) + * James: Matteo is the current chair now given that there was no other +* Update charter with communication responsibilities [#1754](https://github.com/nodejs/TSC/pull/1754) + * James: this is the original proposal to which there’s another alternative being discussed at + the moment + * Joyee: when something happens we need to do post-mortems and be in a position to do so, + empower the team to do something about it + * James: why do you feel that you’re not empowered? + * Joyee: it’s more specific scenarios, somebody else getting in the way, saying no + theoretically on behalf of the foundation + * James: sounds more like a communication process that needs to be improved rather than adding + / tweaking policy to work around that + * Joyee: it’s not intended as a policy but more codifying the practices we have already been + following + * Joyee: for example we remind people who are perceived as representing the project on social + media even when there’s no consensus or people who go to standard bodies speaking on behalf + of the project without collecting consensus. It’s already what we do. Whether they accept + the feedback is up to them but at least the TSC can be empowered to do the calibration + * James: anecdotally companies have been dealing with this since the introduction of social + media, trying things like having employees put notices that their opinions are their own, + but ultimately the public will still associate their personal opinions with their employer + * Joyee: not about what others can do - not in our control. More about what we can be + chartered to do, and not get told to shut up because we are not in a position to do. For + example standards-position repo is not something we are chartered to set up but we already + do it. + * Joyee: open to changes to make the wording reflect more about what we can do, not what + others can or cannot do + * James: maybe some other guide documents might be better than the charter for that specific + purpose + * Joyee: some actor needs to be empowered to take actions in these scenarios, doesn’t need to + be the TSC but TSC is the most likely to take on the work and has been taking on the work, + doubt other parties would be interested in the work + +* Let's talk about the CI situation [#1614](https://github.com/nodejs/TSC/issues/1614) + +### nodejs/admin + +* Create a directory for funding individual contributors [#981](https://github.com/nodejs/admin/pull/981) + +### nodejs/node + +* meta: clarify pr objection process further [#59096](https://github.com/nodejs/node/pull/59096) + +## Strategic Initiatives + +* Skipped as we ran out of time + +## Upcoming Meetings + +* **Node.js Project Calendar**: + +Click `+GoogleCalendar` at the bottom right to add to your own Google calendar.