> We had far less features in 4.1 and it took us 6 months to release. Definitely don't want to derail discussion but I could use some clarity. My current understanding is that the majority of our delay on 4.1 stabilization was due to ASF CI not being stable and switching to also accepting a combination of "green circle + no regressions on ASF compared to prior branches" unstuck us. I know there was one JIRA that had a pretty long tail (think it was streaming, metrics updating, contention timing out related...?) but otherwise I don't recall anything that we could take as an indicator that a next release would take a comparable amount of time to 4.1?
On Fri, Mar 24, 2023, at 2:56 PM, Caleb Rackliffe wrote: > > 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? >>>>>>> >>> >>>>>>> >>>
