> What "phase" this CEP is considered to be production-ready and what Cassandra > release do you plan to do it in? > > 2) What is the risk of you abandoning this CEP in the middle? > > <snip> Is this CEP going to be a one-man show only and if not, who is going > to work on this? OSS == volunteer. It's done when it's done (to reiterate my position from another thread) - at "worst" something would be merged right before a GA branch is cut and you have 3 months of runway before a GA release comes out with a feature.
If a CEP gets abandoned in the middle, that's only a "problem" if it gets merged to trunk before it's completed. Plus, if we keep to: 1. New features being optional / experimental and disabled by default 2. New features being modularized and distinct in the codebase from the rest of the existing code behind clear API / modular boundaries Then I think we should be insulated as a project from people coming and going and work getting picked up or dropped. Worst case it never merges, or if something is merged and then abandoned before it stabilizes and promoted to GA ready, we remove it right? On Tue, Mar 10, 2026, at 8:38 AM, Alex Petrov wrote: >> 1) according to the section called "Project plan", you have divided >> this into "phases". What "phase" this CEP is considered to be >> production-ready and what Cassandra release do you plan to do it in? > > Each phase can be an independent deliverable, and our intention is to keep > committing them to trunk and making them available right away. Of course, we > can keep it all in a feature branch and keep rebasing it, but I do not see a > good reason to do that. In cases where multiple patches would constitute a > logical addition, we will make sure to keep them in a feature branch and > commit together. > >> 2) What is the risk of you abandoning this CEP in the middle? > > I cannot recall any precedent for CEPs being abandoned, particularly > recently, and I do not see any risk of that. > > There has always been a push for delivering CEPs in smaller increments from > the community, and this is what we're intending to do here. Each commit is an > independent improvement. Even if work were to be stopped midway, we would > simply get a bunch of improvements. But I do not see any risk of stopping > midway. > >> 3) You are using the language in your CEP as "we will do", "we will >> allow". Who exactly is "we" in this case? Is this CEP going to be a >> one-man show only and if not, who is going to work on this? Maybe a >> silly question, but I am just genuinely interested in knowing who is >> going to be dealing with this. > > I cannot recall any other CEP getting a question about resourcing, and > unfortunately I cannot go into details of resourcing. Main goal of a CEP is > to socialize a high-level design, which I believe we have done here. > > Regarding timelines, the best answer is "between 6.0 and 7.0". I will do my > best to keep the community with timeline updates and changes. If anyone has > questions about progress at any time during the project, I will be happy to > address them and give updates. > >> This CEP seems to be pretty complicated, from a high-level point of view at >> least. I think the >> relative lack of the questions you received on this CEP might mean >> that people just do not know what to ask. > > Good news is that I already have a working proof-of-concept, which is why I > was able to go deep into a lot of detail. I see no risk of delivery, > especially given the heaviest lifting was done by TCM. I did my best to > evaluate all potential risks while writing a CEP, and I currently do not see > any big unknowns. > > --Alex > > On Tue, Mar 10, 2026, at 9:35 AM, Štefan Miklošovič wrote: >> Hi Alex, >> >> 1) according to the section called "Project plan", you have divided >> this into "phases". What "phase" this CEP is considered to be >> production-ready and what Cassandra release do you plan to do it in? >> >> 2) What is the risk of you abandoning this CEP in the middle? >> >> 3) You are using the language in your CEP as "we will do", "we will >> allow". Who exactly is "we" in this case? Is this CEP going to be a >> one-man show only and if not, who is going to work on this? Maybe a >> silly question, but I am just genuinely interested in knowing who is >> going to be dealing with this. This CEP seems to be pretty >> complicated, from a high-level point of view at least. I think the >> relative lack of the questions you received on this CEP might mean >> that people just do not know what to ask. >> >> 4) Do you also plan to document what you did so we present this CEP to >> users in some digestible way or are they supposed to read the source >> code and your CEP only in order to be productive? >> >> Regards >> >> On Tue, Feb 24, 2026 at 9:18 AM Alex Petrov <[email protected]> wrote: >> > >> > Hi everyone, >> > >> > We'd like to propose CEP-60: Flexible Placements [1] for adoption by the >> > community. Building on CEP-21's Transactional Cluster Metadata [2], CEP-60 >> > enables incremental, resumable operations, improved cluster density, and >> > flexibility of data placements / ownership. >> > >> > CEP-60 benefits all users by further improving reliability of ownership >> > operations. With flexible placements, clusters maintain near-optimal load >> > balance at any size without explicit rebalancing phases. Ownership changes >> > are broken into smaller sub-range steps that benefit from zero-copy >> > streaming. >> > >> > CEP-60 is designed for incremental delivery: range-aware compaction, >> > routing key abstractions, and metrics collection are useful on their own >> > and will ship independently of the flexible placements feature. Existing >> > token-based and vnode clusters will continue to work (while benefitting >> > from incremental ops), and flexible placements can be enabled (and later >> > disabled, if ever needed) on a per-keyspace basis. >> > >> > The CEP is linked here: >> > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-60:+Flexible+Placements >> > >> > Looking forward to the discussion of this CEP here on the dev list. >> > >> > Thanks! >> > >> > [1] >> > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-60:+Flexible+Placements >> > [2] >> > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata >> >
