I think merging repos makes sense but merging analytics (a specific-purpose tool) into sidecar (a general-purpose tool) might make more sense from a user perspective, even if a lot of of the complexity currently lives in analytics. We briefly considered "tools" or "extra" back in the day, but felt that might not convey the long-running nature of the process.
I think it will be confusing to users and contributors if rolling restart behaviors or health monitoring are contributed to "cassandra-analytics". Also just want to double-check: I assume we'd keep published artifacts named the same no matter the repo layout (sidecar clients, analytics-core, etc ...)? -Joey On Wed, Jun 3, 2026 at 9:41 AM Štefan Miklošovič <[email protected]> wrote: > On Wed, Jun 3, 2026 at 1:02 PM Shailaja Koppu <[email protected]> wrote: > > > > Hi Josh, > > > > Thanks for taking care of this. This merge definitely improves > development velocity. Here are my recommendations for outstanding questions. > > > > 1, I prefer to merge both into a new repo something like > cassandra-analytics-and-sidecar, to ensure people don’t think that one of > them vanished or no longer exists/supported > > I think this is just a matter of communication. As said, the > repository of deprecated Sidecar is not going anywhere. We put a big > fat notice that this repo is no longer maintained and all moved to > analytics. People will not think it has vanished because it will be > still present. > > For me the only reason we go with the third repository is to rename > whole cassandra-analytics to something completely different where we > expect software beyond analytics and sidecar to be added in the future > as well. If we start to add things into cassandra-analytics which will > not have necessarily a lot in common while we still wanted to release > it as one thing, maybe creating something like cassandra-ecosystem or > cassandra-platform or similar justifies a third repository to be > created. > > > 2, I prefer the same for Jira as well, something like > CASS-ANALYTICS-AND_SIDECAR or better name if you can come up with one. And > with in that Jira board, separate sub-tags for Analytics and Sidecar, that > way if someone needs only Sidecar tasks, they can apply that sub-tag. And > admins/developers will be able to filter Jiras based on sub-tags. > > 3, Perhaps we can ask authors to migrate their open PRs to the new repo > > 5, Existing repos can be marked as archived and update Readme pages to > redirect incoming developers to the new repo > > > > Thanks, > > Shailaja > > > > > > > On Jun 3, 2026, at 9:30 AM, Štefan Miklošovič <[email protected]> > wrote: > > > > > > More clarification behind that: > > > > > > If we go to merge, it makes more sense to me to merge Sidecar into > > > Analytics than the other way around. Yes, Sidecar also exposes > > > functionality which has nothing to do with Analytics as such but it is > > > still better than merging Analytics into Sidecar, imho. We basically > > > can't use Analytics without Sidecar. Sidecar is inherently part of > > > Analytics. > > > > > > If we were to create a third repository where both are merged, we > > > would need to likely come up with a new name for that project, create > > > a new JIRA subproject ... We would then deprecate both repositories > > > instead of just one and create basically a brand new project. I > > > consider this to be just unnecessary. We would just make everything > > > more complex. > > > > > > From ASF perspective I do not think that we would need to move a > > > repository to deprecate to "Attic". My understanding is that Attic is > > > something where whole projects are moved. We do not have a separate > > > PMC for Sidecar / Analytics so I think that we can just merge these as > > > we want. > > > > > > (1) https://attic.apache.org/ > > > > > > On Wed, Jun 3, 2026 at 10:04 AM Štefan Miklošovič > > > <[email protected]> wrote: > > >> > > >> My (personal) take on this: > > >> > > >> 1) Merging into one repository, no into a new repository. > > >> 2) Retiring CASSSIDECAR and using only CASSANALYTICS. Existing tickets > > >> under CASSSIDECAR can be delivered into a new repository. > > >> 3) Nothing. There are 24 PRs in Sidecar repo, 14 are some "chore". > > >> Converting the rest, even manually, to analytics repo is easy. > > >> 4) maybe we can start to use pre-ci and ci? Why are we so fixated on > Circle? > > >> 5) only cassandra-sidecar will be deprecated, will be marked as read > > >> only / archived, we will not remove it > > >> 6) yes > > >> > > >> On Tue, Jun 2, 2026 at 10:20 PM Josh McKenzie <[email protected]> > wrote: > > >>> > > >>> I'd like to propose we merge the cassandra-sidecar and > cassandra-analytics repositories. I've shopped the idea around to some of > you and gotten universally positive feedback with some questions about > details we deferred to this discussion. > > >>> > > >>> Reasons we should merge: > > >>> > > >>> Break circular dependencies between the 2 projects > > >>> Remove redundant copy/pasted code > > >>> Simplify build and CI > > >>> Reduce friction on changes that span both projects > > >>> Simplify the CDC implementation > > >>> > > >>> > > >>> Outstanding questions and observations that came up: > > >>> > > >>> Do we merge one repository into the other? Or do we create a new > project and bring them both in? > > >>> What do we do about JIRA? Leave separate or combine? > > >>> What do we do with open issues and PR's in github? > > >>> We'll need to thoughtfully update CI (github + circle) since we're > right at the limit on the free tier on both projects > > >>> What do we do about existing deprecated repositories > (cassandra-analytics and/or cassandra-sidecar)? > > >>> We'll need to update our release process > > >>> > > >>> > > >>> Other observations or questions welcome, as are thoughts on the > entire process, on the outstanding questions, etc. > > >>> > > >>> Looking forward to the discussion everyone. > > >>> > > >>> ~Josh > > >
