diff --git a/meetings/2024-08-21.md b/meetings/2024-08-21.md new file mode 100644 index 00000000..282de9f3 --- /dev/null +++ b/meetings/2024-08-21.md @@ -0,0 +1,106 @@ +# Node.js Technical Steering Committee (TSC) Meeting 2024-08-21 + +## Links + +* **Recording**: +* **GitHub Issue**: + +## Present + +* Antoine du Hamel @aduh95 (voting member) +* Yagiz Nizipli @anonrig (voting member) +* Benjamin Gruenbaum @benjamingr (voting member) +* Ruben Bridgewater @BridgeAR (voting member) +* Joyee Cheung @joyeecheung (voting member) +* Chengzhong Wu @legendecas (voting member) +* Marco Ippolito @marco-ippolito (voting member) +* Michael Dawson @mhdawson (voting member) +* Moshe Atlow @MoLow (voting member) +* Rafael Gonzaga @RafaelGSS (voting member) +* Robert Nagy @ronag (voting member) +* Ruy Adorno @ruyadorno (voting member) +* Paolo Insogna @ShogunPanda (voting member) + +## Agenda + +### Announcements + +* Marco 20.17.0 will be released just after this meeting +* Rafael, 22.7.0 will be released tomorrow. + +### 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 this week + +### nodejs/node + +* lib: Symbol.dispose should be enabled with experimental flag [#54329](https://github.com/nodejs/node/pull/54329) + * two issues + * the whole ecmascript feature is unfinished, should there be an experimental warning? + * for the future how do we want experimental global api additions + * in v8 experimental features are hidden behind a flag while incomplete + * the suggestion could be to apply SemVer major for each experimental feature exposed to + the global scope, or basic TSC consensus for each one. + * Marco, generally we should be cautious on polyfills, should likely mark as SemVer major as + the default approach + * Benjamin, in the specific case of Symbol.dispse, it implements the minimum to allow other + tools to prototype and implement. In retrospective, agree it should go through the TSC, + make it SemVer major by default. We have process/tooling to handle that. Last year warning + might have made sense in this specific case, but not so much anymore, but don’t feel to + strongly. + * Michael any concern over policy of making SemVer major by default + * Marco, agree that for specific instance don’t need to do anything, but in the future polyfills + should be SemVer major. + * Chengzhong, when exposed on Global scope -> SemVer major. In addition should it require + an experimental flag to start if feature is incomplete + * Antoine, if we use experimental flag, that is not SemVer major, right? + * Chengzhong, agree without experimental flag SemVer major, but not if it has the + experimental flag + * Benjamin, believe it may depend on the situation, so probably better to mark always as + SemVer major to have it go through the TSC for analysis/discussion. + * Antoine, not sure if we need that for additions which are under a flag. So don’t think + something under an experimental flag should need SemVer major + * Benjamin, if there are cross-cutting concerns that originator is not aware on. + * Antoine, would prefer to just make it informal. + * Marco, not SemVer major in terms of breaking, but is in terms of consensus, so marking as + SemVer major. + * Antoine, not opposed to always be SemVer major if understanding is that it would be + removed after TSC discussion. + * Consensus is + * that we will ask that experimental APIs on the Global scope will always be + marked as SemVer major to start, expectation is that TSC will typically remove after + discussion if its behind an experimental flag. + * won’t add experimental warning to Symbol.dispose + * document the new process in + +* timers: add sleep alias[#54404]( https://github.com/nodejs/node/pull/54404) + * Paolo seems like its easy to mess up + * Benjamin, main concern is that we already have 4-5 ways to schedule a timer + * Paolo, we could remote the override, + * Benjamin, might be better to remove scheduler.wait() + * Michael, is it really worth it, lets document scheduler.wait() better + * Paolo, agree we can just publish scheduler.wait(), but would be good to add warning if you + call setTimeout without await after importing the async version. + * Paolo, could this be SemVer minor. After some discussion seems reasonable to propose, + * Chengzhong, echo scheduler api. Active discussion on experimental api, some discussion in + , about the naming please comment there + if you think it should change. + +### nodejs/admin + +* Conversion to Enterprise account [#905](https://github.com/nodejs/admin/issues/905) + * Issue closed, nothing to discuss. + +## Strategic Initiatives + +## Upcoming Meetings + +* **Node.js Project Calendar**: + +Click `+GoogleCalendar` at the bottom right to add to your own Google calendar.