doc: add minutes for meeting 11 Dec 2024 (#1664)

Signed-off-by: Michael Dawson <midawson@redhat.com>

Author: mhdawson

meetings/2024-12-11.md

@@ -0,0 +1,116 @@
+# Node.js Technical Steering Committee (TSC) Meeting 2024-12-11
+
+## Links
+
+* **Recording**:  <https://www.youtube.com/watch?v=NqtxLJ7_S0g>
+* **GitHub Issue**: <https://github.com/nodejs/TSC/issues/1662>
+
+## Present
+
+* Ruben Bridgewater @BridgeAR (voting member)
+* Gireesh Punathil @gireeshpunathil (voting member)
+* Joyee Cheung @joyeecheung (voting member)
+* Marco Ippolito @marco-ippolito (voting member)
+* Matteo Collina @mcollina (voting member)
+* Michael Dawson @mhdawson (voting member)
+* Rafael Gonzaga @RafaelGSS (voting member)
+* Richard Lau @richardlau (voting member)
+* Ruy Adorno @ruyadorno (voting member)
+* Paolo Insogna @ShogunPanda (voting member)
+
+## Agenda
+
+### Announcements
+
+* No news this week
+
+### 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 updates this week.
+* Matteo, watch Robin’s talk on budget from NodeConf.eu after it is published.
+
+### nodejs/node
+
+* fs: enable chunked reading for large files in readFileHandle [#56022](https://github.com/nodejs/node/pull/56022)
+  * Ruben: do we want the possibility of readfile to read huge files into memory or just accept
+    limit and change the error case. Cannot thinking of use case where it makes sense to load
+    anything bigger than 2G
+    * Michael: Is there some downside to allowing larger sizes? Ruben, on linux it would
+      require multiple reads behind the scenes.
+    * Matteo: people seem to be upset if you try to prevent people from
+      shooting themselves in the foot. Thinks its the right call to keep the limit, but will
+      not oppose if people want to allow it.
+    * Michael: ok if we leave the limit in place. It is possible for people work work around it
+    * Matteo: ok to allow it and crash with out of memory, would accept PR.
+    * Joyee: don’t see a reason to throw and error, if they want to take the risk, document
+      that there are better ways to do it. Would be fine for throw away scripts
+    * Ruben: more worried about people who don’t read the docs, and error would be a way
+      For them to learn about streams
+    * Joyee: we could emit a warning
+    * Ruben: would be ok with allowing and emitting a warning. We could even make the limit
+      a bit lower, say 1G?
+    * Ruben: should we say recommendation is to emit warning and allow
+    * Gireesh, should we emit a warning for a low level function like this?
+    * Ruben, can easily cause the process to crash and out of memory issues, this would be
+      useful to help users understand why they are out of memory.
+    * Joyee could also check how memory is available. Maybe only warn if there
+      is not going to be enough memory.
+    * Gireesh, should documentation not be enough?
+    * Ruben, people don’t read the document often.
+    * Matteo: having the warning at the previous limit is fine. We have other places where
+      There are similar cases (ex more than 10 listeners)
+    * Gireesh: but those are bad coding practice
+    * Matteo: I see this case (loading a file bigger than 2G) is similar
+    * Joyee: agree, if you want to be lazy ok so we don’t want to prevent, but warning is ok.
+    * Ruben: Do we know a legitimate use case for loading a file of this size into memory?
+    * Matteo: top of line mac now has 128g of RAM.
+    * Michael: warning seems like a compromise between not allowing big files and allowing
+      without doing anything.
+    * We did not reach consensus on including a warning
+    * We will leave on the agenda to discuss next week
+
+* test: improve zlib tests [#55716](https://github.com/nodejs/node/pull/55716)
+  * waiting for <https://github.com/nodejs/node/pull/56027> to land as next step.
+
+### nodejs/TSC
+
+* Clarify the Charter so that contractors are explicity counted as affialiated [#1650](https://github.com/nodejs/TSC/pull/1650)
+  * Matteo: ok either way did not plan to be that specific, but happy with suggestion from Ulises
+  * Matteo, perhaps propose something different.
+  * Ruben: it is a rule defined by the TSC for the TSC. We should not overcomplicate things, since we can change this at any point of time
+  * Richard: missing why we have the sentence (about affiliation) in the first place. Lets provide
+    more context as to the goal and leave the the rest less specific.
+  * Matteo: agree doing change in that way would be better.
+  * Michael: would prefer avoiding trying to list the specifics as I doubt we can get it right
+  * Matteo: will do another pass
+
+* Let's talk about the CI situation [#1614](https://github.com/nodejs/TSC/issues/1614)
+  * Richard, Yagiz wanted to talk about the smartOS situation - <https://github.com/nodejs/TSC/issues/1663>
+    * We are in the middle of transitioning some machines. Had a bunch sponsored by
+      Joyent. They were moved to equinix Metal. Equinix then asked that we move our non-arm
+      out of equinix. MNX volunteered to host these machines. Many have been moved over
+      but smartOS ones are still in progress. Also tied with getting the Linux Foundation more
+      Involved.
+    * Matteo suggested we set a deadline. Area of the project that is not getting enough,
+      not enough volunteers, so unless people step up.
+    * Challenge, is that the changes require latest C++, so can’t just exclude tests.
+    * Same PRs -> MacOS and SmartOS are ones that need newer compilers
+    * Richard having deadlines likely helps focus.
+
+* Open OpenCollective and Github Sponsors for Node.js [#1553](https://github.com/nodejs/TSC/issues/1553)
+  * No objections, going to land.
+
+## Strategic Initiatives
+* Skipped as we were 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.