The dilemma here is we’re split between two operating models - free for all open source where volunteers fix bugs and features that matter to them when time permits - large, carefully considered major refactors offered as CEPs by people who are effectively paid to work on Cassandra for their day job, typically because they’re running employer-local Cassandra platforms (usually as internally facing PaaS teams)
Predicting when things finish is hard, because work shows up after the fact and priorities shift, so expecting people to say “this multi-year CEP is done Mar 10 2026” is unlikely to ever be right That said, we can do better than status quo - if you care enough to nominate a CEP and it passes a vote, I suggest you should be obligated to send a monthly/quarterly status update for as long as the CEP is open, and failure to do so implies the CEP is abandoned, and we mark it as such > On Mar 10, 2026, at 7:17 AM, Štefan Miklošovič <[email protected]> wrote: > > While I understand the position of "it's done when it's done" it is > just a little bit sad to see. I mean ... There has to be something > really strange going on when we can not estimate how much time a CEP > is going to take. What are the factors? Is that an issue of planning? > Or people who are involved in these CEPs can not say for sure that > what they work on right now will be on their radar long enough to > materialize that CEP? Should they not also involve this aspect into > their decisions? > > I am trying to understand the dynamics behind this because it is > really interesting to propose a feature while at the same time not > knowing when it happens. > >> On Tue, Mar 10, 2026 at 1:59 PM Josh McKenzie <[email protected]> wrote: >> >> when somebody proposes a CEP and we vote on it, there is practically no >> visibility into WHEN it is going to be delivered. >> >> >> what is wrong with letting people know that it is planned to land in the >> next one? >> >> With history as our guide: we seem to have little ability to forecast or >> plan how long things will take. Some efforts, not just new features, that we >> think will be done in < 1 year end up taking multiple years. >> >> I agree with you in principle Stefan - ideally we'd be able to generally >> signal which major we think a CEP would land in. In practice that's proven >> to not be realistic so I defer to Mick's position. Signaling an incorrect >> major or, even worse, being incentivized to rush something into an early >> merge or release when it's not ready, are both worse outcomes than the >> status quo of "it's done when it's done." >> >> On Tue, Mar 10, 2026, at 6:06 AM, Štefan Miklošovič wrote: >> >> There are people who are anticipating CEPs to be merged and made >> production ready and as of now there is no visibility whatsoever into >> when a user can at least theoretically expect that feature to be in. >> >> I do not think it is completely fair to accept CEPs while not >> discussing the basic timelines about their delivery. >> >> What is wrong with knowing what major a CEP will appear in? It is not >> something to be written in stone, they can be best-effort. >> >> If an author of a CEP _just knows_ that the amount of work needed to >> make a CEP production ready takes more than 1 year and it will not be >> delivered for next major, and they really _know_ this is not going to >> happen in the very next release currently in the preparation, what is >> wrong with letting people know that it is planned to land in the next >> one? >> >> From the point of view of consumers of this software, it would be >> highly appreciated to know when things are going to happen so they can >> plan accordingly. Techops will need to educate themselves to use it, >> consultants need to educate themselves to support it ... We are just >> keeping them in the dark in this regard. >> >> If a feature is not going to land in the next major, and they know it, >> they can just spend more time on something else and not spend time on >> something the author of a CEP knows will not be production ready for a >> long time. >> >>> On Tue, Mar 10, 2026 at 10:38 AM Mick <[email protected]> wrote: >>> >>> >>> >>>> On 9 Mar 2026, at 21:49, Štefan Miklošovič <[email protected]> wrote: >>>> >>>> >>>> Do you think we could shed more light onto actual deliverability of >>>> these CEPs which are landing in Apache wiki recently? >>> >>> >>> >>> >>> >>> That goes against the release train model we agreed on. >>> CEPs by default land in trunk, and will appear in the next major that comes >>> after that merge happens. If it does not land before April then it's in >>> the major after. The merging of any and every CEP should never be rushed >>> ahead of April because someone added to the wiki a release they announced >>> it would be in. Waiting to merge until after April into a fresh trunk is >>> IMHO an act of maturity I hope we can encourage. >>> >>> >>> So from me, it's a no: the answer becomes known when the CEP is merged to >>> trunk. >>> >>> If the links in the CEP to the discussion, the vote and the jira, are kept >>> up to date, then this information should be more than clear and obvious to >>> all. (I am seeing this hygiene lacking.) >>> >>> Otherwise we should document any work dependencies, and steps/milestones in >>> the work, to help illustrate how close a CEP is (without having to ask the >>> engineers for details) :-) >> >>
