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` >>> <https://github.com/apache/cassandra-analytics> and `cassandra-sidecar` >>> <https://github.com/apache/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
