> 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) :-) >
