> 1. 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 Of course, it’s always possible to cherry-pick from open source without contributing back, but the whole point of a community is to engage, collaborate, and shape the project in ways no individual organization could.
When we had doubts about stability of 3.0 some years ago, we created in-jvm dtests to simplify writing tests, then iterated on fuzz tests, and found, reported, and fixed numerous issues. I wonder where we’d be today if we’d been skeptical about CASSANDRA-8099 and just backported what we needed into 2.1 instead of spending that time to harden and qualify the release. I’d encourage folks to engage and collaborate when possible. In the short term, individual organizations may occasionally need to backport fixes, but that should remain a temporary measure. The real solution is a community that can deliver provably stable releases on a collectively acceptable cadence. On Mon, Oct 20, 2025, at 9:24 PM, Josh McKenzie 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: > 1. You need bespoke code to integrate with internal infrastructure > 2. 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 > 3. 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 > 4. 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 >
