Regarding “We should focus on why it took 6 months to go from 4.1 first alpha to GA and what happened inside that time window.” —
Speaking solely from my perspective, the single biggest time draw was tracking down and resolving https://issues.apache.org/jira/browse/CASSANDRA-18110.
One of the strategies we employ to validate a build is to simply run it. Reproducing and resolving this issue was a prerequisite for running the branch and performing further qualification as it blocked host replacements in mercurial circumstances. That work began prior to ApacheCon and was completed in December with continuous focus, but wasn’t something other contributors were able to reproduce (and was difficult for us, too).
Inability to replace a host and run the build slowed subsequent issue-finding/fixing - in many cases past release, with bugs I think we’d have been able to find prior to 4.1.0 if we’d been able to lean harder on it (18194, 18119, 18292, probably a couple others).
I do wish we’d have been able to find the cause of C-18110 faster - or at least its workaround. - Scott On Feb 28, 2023, at 9:06 AM, Benedict <bened...@apache.org> wrote:
I agree, we shouldn’t be branching annually, we should be releasing annually - and we shouldn’t assume that will take six months. We should be aiming for 1-2mo and so long as our trajectory towards that is good, I don’t think there’s anything to worry about (and we’ll get our first comparative data point this release)
On 28 Feb 2023, at 16:02, Ekaterina Dimitrova <e.dimitr...@gmail.com> wrote:
By “not to have to delay again” I mean GA, not the agreement for when to branch and start feature freeze. Just to be clear as I realized I might be misunderstood :-) I agree that November-May falls too short so +1 on postponing the day on my end
Now I think Mick brought excellent point - let’s get into separate discussion about the root cause of releasing 4.1 only in December and see what we need to change/improve on so we do not get into future delays and we do not sacrifice QA of course.
“Postponing" suggests a one-off move, but I'm presuming this would be a permanent change?“
I’d say move it, get to the bottom of how not to have to delay again or at least reduce the window and commit We forked the 4.0 and 4.1 branches beginning of May. Unfortunately, for 4.1 we were only able to release GA in December which impacted how much time we could spend focussing on the next release and the progress that we could do. By consequence, I am wondering if it makes sense for us to branch 5.0 in May or if we should postpone that date.
What is your opinion?
My initial preference is to stick with the May branch and its initial alpha/beta release.
Giving in to the delays doesn't improve the causes of them.
We should focus on why it took 6 months to go from 4.1 first alpha to GA and what happened inside that time window. I'm not convinced summer holidays can be to blame for. I think a lack of QA/CI and folk dedicating time to get it to GA is the bigger problem.
On the QA/CI front I believe we have made significant improvements already. And we saw less releases of 4.1 before its GA. I also think reducing the focus and scope of the subsequent release cycle is a cost that creates the correct incentive, so long as we share the burden of the stabilising_to_GA journey. While it might be difficult for folk to commit their time over summer holidays, the three months of May-July should be way more than enough if we are serious about it.
My thoughts don't touch on CEPs inflight. But my feeling is this should not be about what we want to "squeeze in" (which only makes the problem worse), rather whether the folk that are offering their time to stabilise to GA have a preference for May-July or their September-November.
"Postponing" suggests a one-off move, but I'm presuming this would be a permanent change?
|
