I lean pretty strongly in this direction. I think the only reasonable way to do any custom branch (backport or any other release that deviates from the primary release cycle) would be similar to the original aspects of the CEP process where it required a shepherd. If you want a backport branch, great, but it’s your responsibility to keep it up to date, apply bug fixes, and handle releases. It shouldn’t impact anyone else that hasn’t explicitly volunteered to help maintain it.
I’m opposed to teams solving their technical debt issues by pushing more responsibility onto the project. Jon On Thu, Oct 23, 2025 at 10:14 AM Josh McKenzie <[email protected]> wrote: > To your point Stefan, I honestly think if we: > > - Released a new GA once a year like clockwork > - Cut alphas from trunk every month or 3 months > - Kept CI green (rigorous and pain-free running of pre-commit, git > revert on things that break tests) > - Had new features have the following properties: > - Documented (dev, user, operator, code) > - Off by default; feature flagged > - Thoroughly tested (unit, property, integration, fuzz, jmh perf at > least where appropriate) > > then it'd be easier for someone who wanted to add a new feature to their > fleet to just author it against trunk and qualify the next alpha for their > specific use-case, adopting it fleet wide when the next major hit. > > This would satisfy the "don't want to run a fork" crowd, align with the > "trunk should be releasable" sentiment Ariel drummed on years ago, and help > with the "we need more people to qualify and stabilize trunk" sentiment > Scott rightly expressed. > > So far this seems to improve all the pressures people have brought up for > why they run forks excepting the "need to integrate with my own platform". > > On Thu, Oct 23, 2025, at 12:56 PM, Štefan Miklošovič wrote: > > Great continuation of the original thread. > > > We do not run forks. Our business model is completely different. What > Apache Cassandra releases is what you will get. That's it. Vanilla. So > in some sense when the whole backporting idea was proposed I was kind > of not understanding all of that but I am quite sympathetic to the > problems of others and in some way I feel sorry that you have to all > go through this because we just don't. > > When there is a problem to be solved, first of all we look into how it > might be fixed upstream and be released as part of the official > release. A lot of customers actually want to run "the official thing" > and they do not want to run the forks. Forks are hard to maintain, > each client would be running a different fork, that is hard to track > over time and so on. > > If you are a company which is self-contained and big enough to run > internal fork I get it, but there are also people who don't want to > see any forks, they just want to run the release in its purest form. > Because they trust the community which is driving it more than a > couple individuals who would fork it. > > If we want to make something upstream, there needs to be somebody to > drive and deliver it (me) and ideally who can release it (me). I don't > even need a private CI. Why? We have one, pre-ci. So, I can release > basically whenever I want. Why would I want to have a fork? There is > no reason for that. > > I also think that cooperation in the broader community on your patch > (or patches of others) is better. It gets rid of a whole class of > problems. If I fix some bug or feature, I am most probably fixing it > for somebody else as well and the same holds the other way. Secondly, > the cummulative knowledge of this community is so big that thinking > that an individual with a fork "always knows better" is quite a bold > thinking and I actually want to know what others think about what I am > doing and constructively criticize me for it. > > On Wed, Oct 22, 2025 at 12:34 AM Josh McKenzie <[email protected]> > wrote: > > > > To clarify: I don't think we should try and get rid of all forking and I > didn't read any of our prior or this discussion as that absolute. I think > some reasons for forking are healthy, and other reasons for forking are > redundant and wasteful. We should celebrate the former and try and root out > the latter. > > > > For example: if someone has written a feature to a GA branch and > upstreamed it, and then we don't cut a release for multiple years and don't > cut alphas from trunk, I'd contend our processes are encouraging low-value, > redundant, wasteful fork maintenance. Or forcing people to qualify bespoke > releases from arbitrary SHAs on trunk and running the database based on > that which I expect most people wouldn't be too comfortable doing. > > > > Hence my desire to try and map out why people are forking. For instance: > I think most people could agree that we shouldn't target completely getting > rid of forks for reason #1: "You need bespoke code to integrate with > internal infrastructure". We could take that as a sign to improve users' > lives there by making integration points easier to write to, formalize some > APIs, document them, etc. > > > > On Tue, Oct 21, 2025, at 2:07 PM, C. Scott Andreas wrote: > > > > There’s a common motivation at the root of any fork: having at least one > patch that matters to you – perhaps one you’ve written yourself – and > having complete and total control over your ability to run it. Isaac's > example of C-20749 is a good example of this. > > > > This is the classic story of open source, and for me it’s a positive one. > > > > Releases published by the Apache Cassandra project are solid and stable. > It’s *also* true that many users pretty aggressively editorialize > distributions of the database they deploy. These can include urgent fixes > for bugs they’ve identified and patched; removal/disabling of features they > haven’t qualified; or incubation of patches they intend to contribute > upstream. These are all positive motivations, and something that open > source enables. > > > > I don’t agree that the existence of “forks” is a negative or that > eliminating them is a desirable or achievable goal. Folks will always want > or need to be able to apply a patch that matters to them to solve a problem > or scratch an itch - and they should. > > > > If and as we learn that many users of a particular release have a common > challenge, our process of DISCUSS + backport provides a path to meet that > need, and I think we should exercise it more often. I see Isaac's example > of C-20749 as a good candidate for that as well. > > > > – Scott > > > > On Oct 21, 2025, at 9:12 AM, Isaac Reath <[email protected]> wrote: > > > > > > I'd say the biggest reasons to me are (1) and (2). For example, we > recently worked on CASSANDRA-20749 due to an internal need for this > functionality, and fortunately we’ve been able to bring it upstream. But, > since we run 4.1 and 5.0, we brought this patch back to these versions so > that we are able to use this feature today. > > > > > > To your point in (3), I'd say it's easier to qualify a release built off > of a stable GA than trunk, especially once the GA release has gotten to > where 4.1 is. I’d love to get to the point where we’re qualifying and > running trunk builds in production, but even when we get there I still see > a world where we still need to run the latest GA alongside trunk which > would still motivate us to bring patches back to the latest GA where we > need them. > > > > > > On Mon, Oct 20, 2025 at 3:24 PM Josh McKenzie <[email protected]> > wrote: > > > > > > We had a long conversation about the potential of piloting a supported > backport release branch here: > https://lists.apache.org/thread/xbxt21rttsqvhmh8ds9vs2cr7fx27w3k > > > > When I tried to summarize the thread and identify next steps, one > observation stood out: I think we did a good job establishing the shape of > the challenge we'd like to address (people want to work on OSS, not > maintain private forks), but I don't think we got to the root of why this > challenge exists. If we take action now we run the risk of having the wrong > solution to the right problem. > > > > So: why are people running forks? Some reasons I've seen brought up: > > > > You need bespoke code to integrate with internal infrastructure > > You've written a new feature targeting your internal version, upstreamed > the code, and have to wait for the feature to be in a GA release > > Someone else has contributed a feature to trunk that's attractive and > it's less work or more palatable to back-port it to your private fork and > maintain the diff than to qualify a custom release off trunk > > You have stability concerns with GA releases or running a release based > off trunk > > > > The backport branch we discussed in the previous thread would primarily > address #4 (stability concerns) and secondarily #2 and #3 (feature > availability). All four motivations could be addressed in other > ways—ideally by reducing the pressure to fork in the first place, rather > than accommodating forks as inevitable. > > > > If you're running a fork and open to sharing your experience, do these > reasons match yours, or is something else at play? The more detail we can > gather, the better we can target improvements where they'll actually help. > > > > I know these conversations take time and can be hard; I appreciate > everyone taking the time and energy to help us collectively improve. > > > > ~Josh > > > > > > > > >
