doc: add minutes for meeting 22 Jan 2025 (#1679)

Signed-off-by: Michael Dawson <[email protected]>

Author: mhdawson

meetings/2025-01-22.md

@@ -0,0 +1,142 @@
+# Node.js Technical Steering Committee (TSC) Meeting 2025-01-22
+
+## Links
+
+* **Recording**:  <https://www.youtube.com/watch?v=EpjcRGnCHII>
+* **GitHub Issue**: <https://github.com/nodejs/TSC/issues/1676>
+
+## 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 - <https://github.com/nodejs/reliability/blob/main/reports/2025-01-22.md>
+    * 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 - <https://github.com/nodejs/node/pull/56027> - 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**: <https://nodejs.org/calendar>
+
+Click `+GoogleCalendar` at the bottom right to add to your own Google calendar.