doc: add minutes for meeting 11 Sep 2024 (#1617)

* doc: add minutes for meeting 11 Sep 2024

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

Author: mhdawson

meetings/2024-09-11.md

@@ -0,0 +1,137 @@
+# Node.js Technical Steering Committee (TSC) Meeting 2024-09-11
+
+## Links
+
+* **Recording**:  <https://www.youtube.com/watch?v=mY4hUh5SHPM>
+* **GitHub Issue**: <https://github.com/nodejs/TSC/issues/1615>
+
+## Present
+
+* Antoine du Hamel @aduh95 (voting member)
+* Yagiz Nizipli @anonrig (voting member)
+* Gireesh Punathil @gireeshpunathil (voting member)
+* James Snell @jasnell (voting member)
+* Joyee Cheung @joyeecheung (voting member)
+* Marco Ippolito @marco-ippolito (voting member)
+* Matteo Collina @mcollina (voting member)
+* Michael Dawson @mhdawson (voting member)
+* Richard Lau @richardlau (voting member)
+* Ruy Adorno @ruyadorno (voting member)
+* Paolo Insogna @ShogunPanda (voting member)
+* Guy Bedford (Guest to discuss issue on agenda)
+
+## Agenda
+
+### Announcements
+
+### 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.
+
+* No updates
+
+### nodejs/node
+
+* module: support __cjsUnwrapDefault interop flag in require(esm) [#54563](https://github.com/nodejs/node/pull/54563)
+  * Guy - mostly name bikeshedding issue.
+    * With the introduction for require ESM, working on transpilation of CJS into ESM
+    * Given arbitrary module you don’t know what pattern to apply.
+    * The idea is that adding a marker that tells the original form (ex cjs) it
+      helps in figuring out which pattern to apply.
+    * __cjsUnwrapDefault is the proposal for CJS
+  * Question is should we call this cjsUnwrapDefault or model.exports
+  * Joyee’s suggestion export as model.exports string name
+  * Joyee, one question is that we don’t have agreement to add label to namespace as
+    that might be SemVer major, if we instead add API like isCJS that could be SemVer
+    minor.
+  * Guy, use of new API like isCJS, then does not work for bundlers
+  * Guy: Node.js loader adding a flag is something that other tools could also follow
+  * Need different discussion about polluting the namespace
+  * Guy: Split into 2 PRs one on import and one on require, one on import is tagged as
+    SemVer major, the one for commonJS is marked as SemVer minor.
+  * Antoine: can we clarify are we talking about models written in ESM syntax ?
+  * Joyee: commonJS that has model.exports, now you want to upgrade to ESM, you want
+    to do export.default, that does not translate well. The idea is we need some sort
+    of flag to do the unwrapping properly. Bikeshedding how the hint should be written
+    By the authors. Only useful in cases where you replace module.exports
+  * Antoine: we mean a marker in the model, not a CLI flag right?
+  * Guy: two sides, the require side would allow conversion of module to ESM while
+    maintaining more backwards compatibility.
+    * The other side is support import where
+  * Guy: valid use case for many projects to compile from CJS into ESM. Main goal
+    is the transpilation interopt use case.
+  * Joyee: for those uses cases the name should not matter, really we are bikeshedding
+    the name.
+  * Guy: seems like we are at the point where we are stuck on the bikeshedding.
+  * Joyee: would be in favor of having a vote
+  * Antoine: have we considered only checking if there is a default export, that would
+    avoid having to check a flag?
+  * James: don’t necessarily go to a vote, would be good to give people some time to
+    take a look at the issue first to see if we can reach consensus. Also don’t
+    believe that just using default export will work.
+  * Michael: would be good to have summary of the two choices in the issue to help
+    people jump in.
+  * Guy: seems good to give people some time to jump in.
+
+* deps: V8: backport f320600cd1f4 (V18.x CVE-2024-4761) [#54597](https://github.com/nodejs/node/pull/54597)
+  * Matteo: added, believe we discussed last time. We agreed that we will not backport it
+  * agreed we should remove from the agenda
+
+* Expose Undici's ProxyAgent and setGlobalDispatcher within Node [#43187](https://github.com/nodejs/node/issues/43187)
+  * We discussed last time, there was openness to including more of Undici but not all, remove
+    from agenda for now.
+
+### nodejs/TSC
+
+* Let's talk about the CI situation [#1614](https://github.com/nodejs/TSC/issues/1614)
+  * Antoine: CI is not at its best, very hard to get green CI
+    * flaky tests, either test issue or actual intermittent bugs
+    * macos machines were having disk space issues
+    * opened to discuss how we can do better
+  * Yagiz, in last week a few collaborators reached out to express frustration because it is nearly
+    impossible to land a PR. 5-6 related to flaky tests.
+    * main concern is that collaborators will get frustrated and stop collaborator
+  * Michael: main problem is that we don’t have people who will invest in fixing tests
+  * Yagiz: believe we have too many machines. Linux foundation was supposed to get
+    introduced to our infrastructure and improve
+  * Michael: issue is generally not machines, but tests being actually flaky
+  * Richard: its a combination of issues. MacOS machines have always been tight in space.
+    There have been no changes in the machines. Know issue that at least one test is writing into
+    tmp but eliminated that. If anybody know osx well and can help figure out where the extra
+    Space
+  * Richard: issue snowballs because people are running more builds (probably because of
+    flaky issues). Resume build comes from Jenkins plugin, when you resume it re-runs
+    everything that has not passed including jobs where there were flakes
+  * Richard: don’t think we have an issue detecting flakes, main issue what do we do with flakes
+    once we mark them as flakes. Fundamentally its a resourcing thing where people look at the
+    flakes.
+  * Matteo:
+    * took a look at some of the flakes, typically they are related to timing differences in I/O. http,
+      http, net. Makes it hard to investigate without logging on the machine as it passes locally
+      Easily. In some cases seems impossible to get the same test passing on both systems. 90% are windows tests flaky.
+  * Joyee: We really need some volunteers to look at the flakes, not sure how we can get enough volunteers. 50/50 for flaky
+    tests bug in test or bug in Node.js. Not necessarily test with infra, just occurs on some infra because it exposes
+    the problem. Need to investigate versus just marking as flaky as a memory issue with cause other tests to flake as well.
+  * Richard: If you need access to a machine you can open an issue in build repo to get access
+    to a machine to do investigation.
+  * Yagiz: had open flaky pull request PR which could not land because of other flaky tests.
+    open for more than 10 hours. Can we talk about how we can land those faster.
+  * Michael: we should agree on our approach as that will lead to agreement on how we should
+    address flaky tests.
+  * Joyee: for that specific pull request we should just add another entry to mark the additional
+    test that flaked and run again.
+  * Michael: suggestion is PR to collaborator guide to capture how we handle a specific case in
+    terms of landing even if flaky tests.
+
+## Strategic Initiatives
+* Skipped 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.