I agree with Josh here. If we can’t be adding things that pass review up until the moment we decide to cut the release it means people are not following our stated goals/process for suitability for merge. If that is the case then we should work to fix that, not add arbitrary soft freeze windows to the release timeline.
-Jeremiah > On Mar 8, 2022, at 10:46 AM, Josh McKenzie <jmcken...@apache.org> wrote: > >> We do not want to encourage/enable the rush to commit stuff before the 1st >> May cut-off. IMHO we should be comfortable leaning towards saving any >> significant commits for the next dev cycle. > With sufficient testing added for a new feature, feature flags for > optionality, and a window of time to fuzz test things, why should we shy away > from even large commits the day before we freeze if they have a green CI > board? > > It's up to each of us not to rush or cut corners to try and slip something > in. The snapshot releases and yearly cadence should remove a lot of the sting > from missing a release deadline I think. > > > On Tue, Mar 8, 2022, at 10:14 AM, bened...@apache.org > <mailto:bened...@apache.org> wrote: >> At the very least we should wait until the current issues with CI have >> resolved, so that pending work can merge, before declaring any freeze. >> >> From: Mick Semb Wever <m...@apache.org> >> Date: Tuesday, 8 March 2022 at 15:13 >> To: dev@cassandra.apache.org <dev@cassandra.apache.org> >> Subject: Re: [DISCUSS] Next release cut >> >> >> Should we plan some soft freeze before that? >> >> >> Good question! :-) >> >> We do not want to encourage/enable the rush to commit stuff before the 1st >> May cut-off. IMHO we should be comfortable leaning towards saving any >> significant commits for the next dev cycle. How do we create the correct >> incentive? >> >> If we don't feel that we have achieved stable trunk this dev cycle then a >> soft feature freeze during April makes sense to me. IMHO a need to first cut >> alpha1 instead of going straight to a beta1 is an indicator we have not >> achieved stable trunk; >> >> I'd rather not see a long testing run on the release branch before rc1. And >> I think this is necessary if we want GA by July. >> So for me this boils down to… are we (and will we be) comfortable making the >> first cut 4.1-beta1 ?
