> Do you still want to place it each under cassandra-analytics / > cassandra-sidecar or under cassandra-ecosystem? I view that downloads page as client-facing, so "prioritizing what makes the most intuitive sense to an end-user" is where I default. In this instance, repo structure is a black-box implementation detail users don't need to know anything about, so I'd be inclined to keep them as they are today. If we went with "cassandra-ecosystem" there, then that immediately begs the question of why the client drivers aren't considered part of the ecosystem, etc.
I could envision a future in which we had a cassandra-ecosystem structure w/all the ecosystem projects in it, but that'd be down the road if the root level namespace got crowded enough to become unwieldy. Since we EoL our older release lines and are bound to 3 GA C* releases, I doubt we'll reach that inflection point unless our ecosystem meaningfully expands with new artifacts. > Next, what is going to be the last release of "old" analytics and sidecar? Hm. Good question. Honestly, if we produce a binary from the new repo and it's byte-identical to the old one, I don't know that it actually matters? Maybe it does and there's something I'm missing - seems like a "six of one, half a dozen of another" type situation. > It will be a little bit tricky to update the ecosystem until we are ready for > its release... I thought the same initially but the more I think about it, the more I think it should be straightforward and trivially automatable. In the first phase (before we cut over to using the cassandra-ecosystem repo and freeze the old ones), the repo structure and all .java files should be identical in cassandra-ecosystem to upstream cassandra-* excepting the change in root folder path. Integrating PR's from those other repos should be as easy as taking a diff, applying it directly to the new repo (albeit in a slightly different path), and committing with the same message. So long as we prohibit any new changes in cassandra-ecosystem (i.e. all non-structural, non-new CI, non-new release commits), it should retain that property of upstream changes being trivially mergeable via automation. My mental test of whether this works or not: we could literally, for each PR, just copy and paste all changed files into the new repo and commit using the message and --author of the old and be done with it. Keeping this decoupled and straightforward will definitely require discipline and being clear on what "Phase" we're in; since moving things around and munging with CI and release flows is traditionally kind of a one-person-job (plus review), I'm hoping we can keep things cleanly separated and staged and just grind through it. What do you think? Anything in my reasoning above missing anything? ~Josh On Tue, Jun 30, 2026, at 5:23 AM, Štefan Miklošovič wrote: > 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 > > > > >
