diff --git a/meetings/2025-01-22.md b/meetings/2025-01-22.md new file mode 100644 index 00000000..7cbe9b0d --- /dev/null +++ b/meetings/2025-01-22.md @@ -0,0 +1,142 @@ +# Node.js Technical Steering Committee (TSC) Meeting 2025-01-22 + +## Links + +* **Recording**: +* **GitHub Issue**: + +## Present + +* Antoine du Hamel @aduh95 (voting member) +* Ruben Bridgewater @BridgeAR (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) +* Richard Lau @richardlau (voting member) +* Robert Nagy @ronag (voting member) +* Ruy Adorno @ruyadorno (voting member) +* Paolo Insogna @ShogunPanda (voting member) +* Joe Sepi @joesepi (Guest - Node.js CPC rep) +* Joshua M. Clulow (Guest: illumos/SmartOS platform) +* Brie (Guest: illumos/SmartOS platform) + +## Agenda + +### Announcements + +* Matteo: Organization for collaborator summit is under way, please submit session if you would like to have one, and if you need travel funding please submit request as well. +* Richard: Security releases this week, please upgrade accordingly + +### 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 + +*Extracted from **tsc-agenda** labeled issues and pull requests from the **nodejs org** prior to the meeting + +* CPC updates + * Joe: board meeting this week. So if anything to be brought up let Joe or Matteo know +* Matteo, also mentioned to reach out to him if there is anything to be brought to the board + +### nodejs/node + +* doc: change smartos support type to experimental [#56220](https://github.com/nodejs/node/pull/56220) + * Matteo, @anonrig had proposed lowering to experimental, and possibly removing + from the regular CI runs + * Marco, some issues for the 20.x staging, have not started CI yet, failing before on SmartOs + * James, appreciate the increased effort, key issue has been issues blocking progress on + PRs, which is what Yagiz experienced, have experienced those as well. As we make + on improving support for the machines would be good to have agreement on what + we do to move forward. + * Brie if something has been known to be flaky, then ok with skipping. But if it was known + to be stable then I would like to have that be investigated. + * Joshua, tests which are flaky should be marked as flaky + * Matteo: in the past, what has been done for certain platforms, put in test, skip the test + * Michael: and platform teams have been, ok based on understanding and can prioritize + when to fix that. + * Michael: To James point, as work is done to improve, can we set a time after an + at mention to the smartOS team, its ok to skip after 5 days. + * Joshua that would be good for us + * James sounds good for us as well + * James every flaky test should have a test. + * Michael: in terms of releases, will continue to ping team and discuss in the release issue + * Joshua, was hoping to assign issue to people and label them, but don’t seem to be + able to do that. + * general consensus, leave it as it is for now, and see how progress goes in terms + of improving responsiveness. + * James will talk to Yagiz to update and ask if he would be ok in removing from agenda for + now. To be added back if progress is not made + * Matteo, some work to be done with respect to reliability CI repo. That documents the + CI failures - + * reliability report is a good place to look and chase down failures + * skipping it ok, particularly if platform team is comfortable skipping. + +* test: improve zlib tests [#55716](https://github.com/nodejs/node/pull/55716) + * two topics + * migrate to use test runner + * changing test structure + * discussing both together is making the discussion harder to progress + * This one in particular is about whether to use test runner as much as possible + * PR - - to set policy + * Chengzhong, seems like we don’t have consensus in the PR yet + * James, not going to engage in the conversation, to frustrating, conversation for me is not + healthy + * problem is that we have new contributors, they open PRs and get discouraged because + they are blocked without interesting + * Joyee, 2 kinds of PRs, one not related to style, others which change to style of their liking, + those are more debatable, and more risky. + * Michael, fundamental issue is that we don’t have consensus on moving all tests to test + running. Agree with Joyee that we should not recommend new collaborators to make + stylistic changes unless it is agreed/documented that the project wants to move in + that direction. + * Joyee, node-test is unrelated, but good to have guidelines in terms of what we should + add to the tests. Still not convinced stylistic changes are good for backports + * Marco, from the point of view of a Releaser, migrating tests for the sake of migrations will + cause a lot of work/headaches, migrating for for the sake of migrating, + * Ronag, don’t think we are addressing the key issue, more documented should be easier, but + the rest introduce the change people are concerned about + * Matteo: personally there is will from 3rd party runtimes to say they are Node.js compatible + by running the tests. Test suite was not built with that in mind and creating a certification + program for other runtimes is a lot of effort and that only really matters for those who + develop other runtimes. Not sure how to solve, except to create separate certification + Suite. Not convinced the current test suite is the starting point for that. + * James, work is not necessarily using node-test, but figuring out how to move in that + direction. + * Joyee, node-test encourages grouping files, which may not be great for James use case. + * Michael for the original issue what we need is more specific direction/documentation. For example, + one option that allows forward progess but not adding too much work for the project would be + to only accept stylistic changes along with other changes to tests fix problems with the + test, reduce flakiness etc. That might be too slow to achieve James' goals though. What we really + need is to agree on direction and document it, so that we avoid people being surprised\ + when they propose stylistic only changes. + * Ronald, thinkig about ideas that might work, how about a new set of tests, and project runs both? + * James, will likely develop other test suite. + * Joyee, that sounds like what I suggested a while ago. We don’t ask other runtimes + so that they can run their tests on Node.js + +### nodejs/TSC + +* Clarify the Charter so that contractors are explicitly counted as affiliated [#1650](https://github.com/nodejs/TSC/pull/1650) + * CPC approved, Matteo will land after meeting + +* doc: add funding goals [#1678](https://github.com/nodejs/TSC/pull/1678) + * Michael, TSC members please take a look and comment/approve + +* Let's talk about the CI situation [#1614](https://github.com/nodejs/TSC/issues/1614) + * skipped this week as we ran out of time + +* Status of smartOS support and what future holds [#1663](https://github.com/nodejs/TSC/issues/1663) + * Covered in discussion above + +## Strategic Initiatives +* skipped this week 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.