> > We also have the requirement that there will be no release without green > CI. Do we cut a release branch on the 1st May if we don't yet have a green > CI and can't be making a cut off it?
I would propose to create the new branch on the 1st of May and consider it feature freeze. We can then look at its state. If we have minor issues, fix them otherwise rollback the problematic changes. Having a green CI should be our priority today as it will allow us to minimize the risk of introducing new issues as we progress toward the release. Le mer. 9 mars 2022 à 01:20, Ekaterina Dimitrova <e.dimitr...@gmail.com> a écrit : > I tend to agree with Mick. We should have a bit of time to look around and > do a final cross check. Also, our CI is really painful these days and I am > not talking only about test failures, but infra. > > On Tue, 8 Mar 2022 at 13:56, Mick Semb Wever <m...@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? >>> >> >> >> Yes, we are aligned here. If things are done properly then that's not "a >> rush", and there's no reason we shouldn't be _working as normal_ up until >> the 1st May. Keeping in mind that the time to do it properly can be >> something out of your control: CI not working, rebasing if there's a lot >> landing in trunk, etc. >> >> We also have the requirement that there will be no release without green >> CI. Do we cut a release branch on the 1st May if we don't yet have a green >> CI and can't be making a cut off it? >> >>
