+1 On Tue, Sep 1, 2026 at 4:06 AM Bernardo Botella < [email protected]> wrote:
> +1! > > *From: *Yifan Cai <[email protected]> > *Date: *Tuesday, 1 September 2026 at 08:08 > *To: *[email protected] <[email protected]> > *Subject: *Re: [DISCUSS] CEP-65: cassaudra-utils - A shared utility > library for the cassandra ecosystem > > +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. > > > > > > > >
