Hi Josh, just went through the drafted CEP of yours.
Looks good, I am curious what we plan to do with this https://downloads.apache.org/cassandra/ Do you still want to place it each under cassandra-analytics / cassandra-sidecar or under cassandra-ecosystem? I think the latter (dedicated cassandra-ecosystem) makes more sense, right? We might keep cassandra-{analytics/sidecar} for the record there (actually, we probably have to), but since we are merging into a new repository then it should be released under cassandra-ecosystem dir, no? Next, what is going to be the last release of "old" analytics and sidecar? We will do one more 0.5.0 of each the old way or the next one is going to be cassandra-ecosystem? I don't mind either way. I think this is something we need to agree on and will be influenced by the adoption of this CEP. It will be a little bit tricky to update the ecosystem until we are ready for its release. To offload anybody doing this, maybe it would be better to instruct devs to just start to contribute to the ecosystem once the ecosystem repo is created and in a buildable state. We can freeze the old repos way before the ecosystem is technically ready to be released, it will at least make the devs motivated to roll over to the ecosystem line of thinking knowing they will not get another analytics/sidecar release. Regards On Thu, Jun 25, 2026 at 7:17 PM Josh McKenzie <[email protected]> wrote: > > Thanks for the feedback Bernardo! > > What about adding some details on the “Proposed Changes” section about the > current building scripts and how they are going to be merged? > > My instinct with stuff like this is to try and target the smallest scoped > change and do things discretely. In this case that would translate into > "naively merge the two build systems together, decoupling / disambiguating > duplicate gradle task names, and defer fixing the build and making the devx > nice to a subsequent effort". I 100% agree w/you that not only will having > the projects merged really facilitate us cleaning up the build process, but > also that they could use some love and attention. > > I've been chatting w/Yifan quite a bit about this topic in the past couple > weeks - whether CEP's are forward-looking design docs or primarily mechanisms > for us to get early alignment and consensus up front for potentially fraught > topics. I've been approaching them as the latter (fraught early alignment) > but I'm coming around to thinking that's too reductive and leaves value on > the table. > > So with all that long-winded meta-analysis, I fully accept your point and > I'll refine the draft on that front. I'm in the middle of doing exactly that > on another related project and some of those changes will directly apply here > (things like auto checking for localhost availability for in-jvm dtests in > gradle and early failing on integration tests w/instructions on how to fix, > auto-building dtest jars as part of the build process, etc). > > while this change does take place, new features and additions will be frozen > to the soon to be deprecated repositories. But, what about security fixes, > bugs, etc? Do we have a plan to address them while doing this merge? > > I think I should refine what I'm proposing on the timeline so it's clearer > because the CEP should address this. There's basically 2 binary "phases" to > this: > - Pre: everyone still works on cassandra-analytics and cassandra-sidecar > while someone (i.e. me (i.e. claude)) sets up cassandra-ecosystem. All work > goes "upstream" and I merge it into the ecosystem repo. In theory this should > be trivial since I'll just be changing locations and changing build files, > not aggressively changing the code or refactoring at this time. > - Post: Once we've cut a release from ecosystem and the whole stack is up and > working and the code is identical to upstream (i.e. all PR's merged in, etc), > we freeze the 2 upstream and all work goes into ecosystem. > - Post++: We work on removing duplicated code in the merged repo and do the > above "clean up and augment the build system" work. > > Transition from Pre to Post happens when all changes from the old repos are > reflected in ecosystem, CI is green, and we successfully cut releases from > it. And I email the dev list w/warning and get consensus on it. There's > always 1 canonical place for the community to contribute to for sidecar or > analytics work and a discrete point in time where that location cuts over. > > That clarify? If so I can take a crack at refining the text in the CEP to try > and make that more clear. > > On Wed, Jun 24, 2026, at 9:00 PM, Bernardo Botella wrote: > > This is awesome Josh!! Thanks a lot for putting this all together. I love > what I’ve read. > > If I had to nitpick, I’d like for it to have a little bit more attention to > the actual unification of builds. What about adding some details on the > “Proposed Changes” section about the current building scripts and how they > are going to be merged? Right now, they are basically both copy pasta from > the main Cassandra build scripts. I don’t think we should fix that copy pasta > on this effort by any means, but we are at least merging those two copy > pastas (sidecar and analytics) into one copy pasta (ecosystem). Having it in > this CEP turns the actual building process into a first class citizen, and > rightfully so in my opinion. > > Also, I guess that while this change does take place, new features and > additions will be frozen to the soon to be deprecated repositories. But, what > about security fixes, bugs, etc? Do we have a plan to address them while > doing this merge? (Just in case it drags in time). > > Other than that, eager to see the artifacts 0.6.0 released from here. :-) > > Thanks! > Bernardo > > > > El El mar, 23 jun 2026 a las 1:10 a. m., Josh McKenzie <[email protected]> > escribió: > > > CEP Draft: > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=435028087 > > DISCUSS ML thread on the topic that led to the CEP: > https://lists.apache.org/thread/slpn99x51yxmrhg9oncb5olq9kjqj5js > > From the CEP: > > This CEP proposes consolidating the two separate Apache Cassandra companion > repositories - cassandra-analytics and cassandra-sidecar - into a single new > repository, cassandra-ecosystem, and establishing the versioning, release, > API-stability, and CI practices needed to make co-location safe for existing > production consumers. > > > We had some solid discussion and a pretty clear consensus on the direction. > The CEP contains more opinionated language and proposals around moving from > our hybrid JIRA + github project management to pure github. The API > compatibility contract and release/versioning model are also new (we talked > about them on the DISCUSS thread but new to the projects) so definitely > curious to hear what everyone thinks now that it's more fleshed out in the > CEP. > > And sorry it ended up being longer Ekaterina :); once I started digging into > the nuts and bolts of it there's a lot of ground to cover. I really > appreciate all the engagement on the previous DISCUSS thread and am looking > forward to more of that same energy here. > > ~Josh > >
