> That does not mean that the code should not be stabilized before the release. We had far less features in 4.1 and it took us 6 months to release. Accepting more features until August will probably result in extending the time needed to stabilize the release.
I think what I'm trying to get at is that CEP-21/TCM is almost certainly the most invasive piece of work that will be in the release. This probably means... 1.) "Stabilization" work for anything it touches before it merges will be of limited value. 2.) No matter what else goes in before it merges, it will probably be the bottleneck for stabilizing the release. If we want to cut a release after TCM merges, let's cut a 5.0 branch, stabilize it, and let SAI, Accord, et al. merge to trunk and appear in the next release. If SAI or Accord are ready at roughly the same time, having already been based on TCM in their feature branches and extremely well-vetted (Harry, performance testing, simulator exposure), we can have the discussion about merging them and then cutting a release branch. On Fri, Mar 24, 2023 at 1:39 PM Benjamin Lerer <b.le...@gmail.com> wrote: > SAI, Accord, UCS, and DDM are all features that can be pretty safely >> disabled/not used, and unlike w/ CEP-21, we *should* be able to de-risk >> those things much more easily before they merge. > > > That does not mean that the code should not be stabilized before the > release. We had far less features in 4.1 and it took us 6 months to > release. Accepting more features until August will probably result in > extending the time needed to stabilize the release. > > I worry about the labor involved with having very large work like this >> target a frozen branch and then also needing to pull it up to trunk. That >> doesn't sound fun. >> > I am not sure I understand the issue of merging the work in a frozen > branch. Should it not facilitate the work if the branch stops changing > heavily? Regarding trunk, if most of us focus on stabilizing the 5.0 branch > or on CEP-15 and 21 I do not think that it will change so much. Am I > missing something? > > Le ven. 24 mars 2023 à 19:16, Caleb Rackliffe <calebrackli...@gmail.com> > a écrit : > >> > I worry about the labor involved with having very large work like this >> target a frozen branch and then also needing to pull it up to trunk. That >> doesn't sound fun. >> >> > I for one do not like to have release branches cut months before their >> expected release. >> >> > CEP-15 is mostly “net new stuff” and not “changes to existing stuff” >> from my understanding? >> >> Yes, yes, and yes. Agree w/ JD here. If we want CEP-21 to make it into >> 5.0, I'd oppose freezing a 5.0 branch for QA until it merges. >> >> SAI, Accord, UCS, and DDM are all features that can be pretty safely >> disabled/not used, and unlike w/ CEP-21, we *should* be able to de-risk >> those things much more easily before they merge. >> >> To try to address Mick's question, assuming we have Accord depending on >> TCM, I'm not sure how closely it can follow TCM in merging. We've been >> talking about this In another thread: "[DISCUSS] cep-15-accord, >> cep-21-tcm, and trunk", but trying to rebase cep-15-accord on cep-21-tcm >> is probably the easiest way to minimize that window... >> >> On Fri, Mar 24, 2023 at 10:41 AM Benjamin Lerer <ble...@apache.org> >> wrote: >> >>> I’m not sure what freezing early for “extra QA time” really buys us? >>> >>> >>> Tries, SAI, UCS, extended TTLs, Java 17, Dynamic Data Masking... all >>> those changes potentially introduce their set of issues/flakiness or other >>> problems. The freeze will allow us to find those early and facilitate the >>> integration of CEP 21 and 15 in my opinion. >>> >>> Le ven. 24 mars 2023 à 16:23, Jeremiah D Jordan < >>> jeremiah.jor...@gmail.com> a écrit : >>> >>>> Given the fundamental change to how cluster operations work coming from >>>> CEP-21, I’m not sure what freezing early for “extra QA time” really buys >>>> us? I wouldn’t trust any multi-node QA done pre commit. >>>> What “stabilizing” do we expect to be doing during this time? How much >>>> of it do we just have to do again after those things merge? I for one do >>>> not like to have release branches cut months before their expected >>>> release. It just adds extra merge forward and “where should this go” >>>> questions/overhead. It could make sense to me to branch branch when CEP-21 >>>> merges and only let in CEP-15 after that. CEP-15 is mostly “net new stuff” >>>> and not “changes to existing stuff” from my understanding? So no QA effort >>>> wasted if it is done before it merges. >>>> >>>> -Jeremiah >>>> >>>> On Mar 24, 2023, at 9:38 AM, Josh McKenzie <jmcken...@apache.org> >>>> wrote: >>>> >>>> I would like to propose a partial freeze of 5.0 in June >>>> >>>> My .02: >>>> +1 to: >>>> * partial freeze on an agreed upon date w/agreed upon other things that >>>> can optionally go in after >>>> * setting a hard limit on when we ship from that frozen branch >>>> regardless of whether the features land or not >>>> >>>> -1 to: >>>> * ever feature freezing trunk again. :) >>>> >>>> I worry about the labor involved with having very large work like this >>>> target a frozen branch and then also needing to pull it up to trunk. That >>>> doesn't sound fun. >>>> >>>> If we resurrected the discussion about cutting alpha snapshots from >>>> trunk, would that change people's perspectives on the weight of this >>>> current decision? We'd probably also have to re-open pandora's box talking >>>> about the solidity of our API's on trunk as well if we positioned those >>>> alphas as being stable enough to start prototyping and/or building future >>>> applications against. >>>> >>>> On Fri, Mar 24, 2023, at 9:59 AM, Brandon Williams wrote: >>>> >>>> I am +1 on a 5.0 branch freeze. >>>> >>>> Kind Regards, >>>> Brandon >>>> >>>> On Fri, Mar 24, 2023 at 8:54 AM Benjamin Lerer <ble...@apache.org> >>>> wrote: >>>> >> >>>> >> Would that be a trunk freeze, or freeze of a cassandra-5.0 branch? >>>> > >>>> > >>>> > I was thinking of a cassandra-5.0 branch freeze. So branching 5.0 and >>>> allowing only CEP-15 and 21 + bug fixes there. >>>> > Le ven. 24 mars 2023 à 13:55, Paulo Motta <pauloricard...@gmail.com> >>>> a écrit : >>>> >> >>>> >> > I would like to propose a partial freeze of 5.0 in June. >>>> >> >>>> >> Would that be a trunk freeze, or freeze of a cassandra-5.0 branch? I >>>> agree with a branch freeze, but not with trunk freeze. >>>> >> >>>> >> I might work on small features after June and would be happy to >>>> delay releasing these on 5.0+, but delaying merge to trunk until 5.0 is >>>> released could be disruptive to contributors workflows and I would prefer >>>> to avoid that if possible. >>>> >> >>>> >> On Fri, Mar 24, 2023 at 6:37 AM Mick Semb Wever <m...@apache.org> >>>> wrote: >>>> >>> >>>> >>> >>>> >>>> I would like to propose a partial freeze of 5.0 in June. >>>> >>>> >>>> >>>> … >>>> >>>> >>>> >>>> This partial freeze will be valid for every new feature except >>>> CEP-21 and CEP-15. >>>> >>> >>>> >>> >>>> >>> >>>> >>> +1 >>>> >>> >>>> >>> Thanks for summarising the thread this way Benjamin. This addresses >>>> my two main concerns: letting the branch/release date slip too much into >>>> the unknown, squeezing GA QA efforts, while putting in place exceptional >>>> waivers for CEP-21 and CEP-15. >>>> >>> >>>> >>> I hope that in the future we will be more willing to commit to the >>>> release train model: less concerned about "what the next release contains"; >>>> more comfortable letting big features land where they land. But this is >>>> opinion and discussion for another day… possibly looping back to the >>>> discussion on preview releases… >>>> >>> >>>> >>> >>>> >>> Do we have yet from anyone a (rough) eta on CEP-15 (post CEP-21) >>>> landing in trunk? >>>> >>> >>>> >>> >>>> >>>> >>>>
