I think this is a great idea (as you know Josh ;-) ) I would love to work on Constraints being back ported
Regards, Bernardo > On Oct 6, 2025, at 12:56 PM, Patrick Lee <[email protected]> wrote: > > 100% in favor and how ever i can be involved here i'm game! I've been > involved with deciding to have our own internal fork for this purpose but > there is some hesitation for the same reason that Jaydeep says. I did early > on backport CEP-37 for Cassandra 5 and was running tests before it was merged > into trunk but we didn't go beyond that. We have a lot of 4.0 and 5.0 in our > fleet as we basically overlooked 4.1. So having things like CEP-37 in a 5..0 > code base i'm all in! > > On Mon, Oct 6, 2025 at 1:42 PM Jaydeep Chovatia <[email protected] > <mailto:[email protected]>> wrote: >> Totally in support of this idea. As we know, CEP-37 has already been merged >> into the trunk. However, many individuals who are not on the trunk have been >> using the CEP-37 work on 4.1. Therefore, I have been maintaining a private >> fork >> (https://github.com/jaydeepkumar1984/cassandra/tree/auto_repair_v2_on_4_1), >> which is quite painful to manage. I have more 4.1 users inquiring about >> using this, as they are now aware that the CEP-37 4.1 work is already in use >> by Cassandra operators and is pretty stable, and they are already on 4.1. So >> more and more folks are going to rely on my private fork, which is not a >> great idea either. >> >> I am in favor of officially supporting these features backport. Of course, >> we collectively vote on which features to backport and which ones not to. >> >> Jaydeep >> >> On Mon, Oct 6, 2025 at 11:35 AM Isaac Reath <[email protected] >> <mailto:[email protected]>> wrote: >>> I’m in favor of this idea for all of the reasons Josh mentioned and I’m >>> happy to help out with the curation and maintenance. Consolidating these >>> efforts seems like a clear win to anyone who is already managing their own >>> fork of backports. >>> >>> A couple of questions that come to mind: >>> >>> 1) What is the inclusion criteria for a patch to get backported? >>> >>> 2) What does the lifecycle of this branch look like? If we use the example >>> of a cassandra-5.1 branch, what happens to this branch after 6.0 is GA? I >>> think there should be some grace period after the next version is cut where >>> this branch is still active, but we probably don't need as long of a >>> support model as the "main" (i.e. 4.0, 4.1, 5.0, 6.0) releases. >>> >>> >>> On Mon, Oct 6, 2025 at 1:39 PM Rahul Singh (ANANT) <[email protected] >>> <mailto:[email protected]>> wrote: >>>> Makes sense. Does this become "LTS" ? or is this something else. >>>> >>>> >>>> On Mon, Oct 06, 2025 at 04:03 PM Josh McKenzie wrote: >>>>> On Mon, Oct 06, 2025 at 04:03 PM Josh McKenzie wrote: >>>>> Many large‑scale Cassandra users have had to maintain private feature >>>>> back-port forks (e.g., CEP‑37, compaction optimization, etc) for years on >>>>> older branches. That duplication adds risk and pulls time away from >>>>> upstream contributions which came up as a pain point in discussion at CoC >>>>> this year. >>>>> The proposal we came up with: an official, community‑maintained backport >>>>> branch (e.g. cassandra‑5.1) built on the current GA release that we pilot >>>>> for a year and then decide if we want to make it official. The branch >>>>> would selectively accept non‑disruptive improvements that meet criteria >>>>> we define together. There’s a lot of OSS prior art here (Lucene, httpd, >>>>> Hadoop, Kafka, Linux kernel, etc). >>>>> Benefits include reduced duplicated effort, a safer middle ground between >>>>> trunk and frozen GA releases, faster delivery of vetted features, and >>>>> community energy going to this branch instead of duplicated on private >>>>> forks. >>>>> If you’re interested in helping curate or maintain this branch - or have >>>>> thoughts on the idea - please reply and voice your thoughts. >>>>> ~Josh >>>> >>>>
