+1 on starting with testing in order to make incremental progress. I'd still call anything shared across multiple projects an API, but I'm fine loosening that bar for the testing module specifically when we're just getting started.
- Yifan On Mon, Aug 31, 2026 at 11:07 AM Ekaterina Dimitrova <[email protected]> wrote: > Makes sense to me. I am all in for incremental work whenever it makes sense > > Best regards, > Ekaterina > > On Mon, 31 Aug 2026 at 14:04, Štefan Miklošovič <[email protected]> > wrote: > >> +1 starting with testing. Let's have something well scoped so we can >> exercise the whole machinery first. >> >> On Mon, Aug 31, 2026 at 7:43 PM Josh McKenzie <[email protected]> >> wrote: >> > >> > What do we think about starting with testing and deferring concurrency >> and collections? The two seem to have very different needs in terms of API >> lifecycle and evolution so having a policy tailored to the right balance of >> producer vs. consumer needs makes sense to me. >> > >> > On Mon, Aug 24, 2026, at 1:11 PM, Josh McKenzie wrote: >> > >> > Can see how that'd come across as a false dichotomy; not my intent or >> mental model. What I was thinking and shorthanded poorly was - if we said >> "you need to run CI on all dependents and confirm no regression", that >> makes utils the single highest-toil place in the ecosystem to get code >> merged. You'd have to do the A/B triage of your run to a control for every >> project that consumes it. Definitely not "block on green" - I glossed over >> that poorly. >> > >> > There's also an opportunity for us to automate LLM-based triage of >> flaky or failing tests to help burn those down, potentially giving us a >> state where we actually had green CI ecosystem wide for the first time in >> over a decade. That'd change the calculus here quite a bit and just make >> utils merges long / high compute but not a flaky CI nightmare. >> > >> > On Mon, Aug 24, 2026, at 5:36 AM, Mick wrote: >> > >> > >> > > 1. full CI pass on everything puts a dependency on us having >> > > consistently green CI or utils becomes the single worst place to try >> > > and get something merged in the ecosystem. We haven't had consistent >> > > green CI in the 12 years I've been around; I don't see how we're going >> > > to start now. This would probably make utils DOA. >> > >> > >> > Nit: this is presenting a false dichotomy, imho. NOT green means >> harder/headache but not "not usable/valuable". Green is not a dependency, >> and I don't think that should be presented as a reason to do less testing. >> > >> > Moving towards (3) should instead be based on what downstream testing >> do we need. If we agree that some set of unit, property and fuzz testing >> puts us in a safe place (and every downstream agrees) that should be enough >> to warrant the minimalisation fo what CI to run. >> > >> > >> > >> >
