>
> I'd be happier with something concrete like the following expected release
> flow:
>
> 1) We freeze a branch
> 2) To hit RC, we need green circle + no regression on ASF (or green ASF in
> the future when stable)
> 3) We need N weeks in this frozen state for people to test it out
> 4) Once we ha
> in practice we wait and receive bug reports from downstream testing efforts.
> Such testing isn't necessarily possible pre-commit, e.g. third-party and not
> feasible to continuously run, nor appropriate to upstream/open-source.
>
> We want GA releases to be production ready for any cluster at
> We have a lot of significant features that have or will land soon and our
> experience suggests that those merges usually bring their set of
> instabilities. The goal of the proposal was to make sure that we get rid of
> them before TCM and Accord land to allow us to more easily identify the
> ro
That was my understanding as well.On Mar 30, 2023, at 11:21 AM, Josh McKenzie wrote:So to confirm, let's make sure we all agree on the definition of "stabilize".Using the definition as "green run of all tests on circleci, no regressions on ASF CI" that we used to get 4.1 out the door, and combine
So to confirm, let's make sure we all agree on the definition of "stabilize".
Using the definition as "green run of all tests on circleci, no regressions on
ASF CI" that we used to get 4.1 out the door, and combined with the metric of
"feature branches don't merge until their CI is green on at l
>
> 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?
Do we have any indicator that proves that it will take less time? We never
managed to do a release in 2 or 3 months so far. Until we have actually
prov
Not so fast...
There's certainly value in spending that time stabilizing the already done
features. It's valuable triaging information to say this used to work
before CEP-21 and only broke after it.
That said, having a very long freeze of trunk, or alternatively having a
very long lived 5.0 branc
> 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
comb
> 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
>
> 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 featu
> 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 n
>
> 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
integr
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
On Tue, 7 Mar 2023 at 11:20, Sam Tunnicliffe wrote:
> Currently, we anticipate CEP-21 being in a mergeable state around late
> July/August.
>
For me this is a more important reason to delay the branch date than
CEP-15, it being such a foundational change. Also, this is the first
feedback we've
Currently, we anticipate CEP-21 being in a mergeable state around late
July/August. We're intending to push a feature branch with an implementation
covering much of the core functionality to the ASF repo this week. Doing so
will obviously help us get a better idea of the remaining work as we
in
15 matches
Mail list logo
