Seems this discussion died, and I would like to restart it. With 2.7.0 being released, we should consider this change for the 2.8.0 release plan. Given that 2.7.0 was delayed by 6 weeks, I believe that the proposed changed would help us to ship releases more timely.
-Matthias On 9/30/20 10:20 PM, Matthias J. Sax wrote: > I added one week between KIP freeze and feature freeze as my observation > was that we tend to vote some last minutes KIPs and than rush the > implementation within one week. Having two weeks to implement last > minute KIPs should lead the a more stable release branch when we cut it > after feature freeze, with hopefully fewer last minute critical/blocker > bugs. > > I also added one more week after code freeze, because this is the period > we need to just stabilize the release branch. We had many blockers in > the last releases that delayed the whole process. Thus, accommodating > one more week seems to be an adjustment to reality. And because we only > merge blocker fixes, it should not introduce any new risks. > > Let me know if this reasoning make sense. In the end, it's a proposal -- > I am more than happy to consider other ideas. I just wanted to put out > something concrete, instead of a vague "we should change something" > statement. > > > -Matthias > > > On 9/30/20 8:38 PM, Ismael Juma wrote: >> Thanks for proposing this Matthias. A couple of questions: >> >> 1. How did you decide where to increase the time? >> 2. Do you think there's a risk that having more time won't necessarily >> help, we will just try to fit more things? I've seen that happen in similar >> circumstances. >> >> Ismael >> >> On Tue, Sep 29, 2020, 7:29 PM Matthias J. Sax <mj...@apache.org> wrote: >> >>> Hi, >>> >>> when we introduced time based releases, we added certain deadlines to >>> streamline the release process and to make sure we can ship the release >>> on time. Based on early experience, we adjusted those deadlines and >>> introduced new deadlines which improved the situation. >>> >>> However, we still have the issue that it often takes very long to >>> stabilize a release branch and the release was delayed by several weeks. >>> >>> Thus, I am wondering if we should adjust those deadlines again. >>> Currently, we have >>> >>> - KIP freeze >>> - Feature freeze (+1 week) >>> - Code freeze (+2 weeks) >>> - Target release date (+2 weeks) >>> >>> I would like to propose to extend the deadlines as follows: >>> >>> - KIP freeze >>> - Feature freeze (+2 weeks) >>> - Code freeze (+2 weeks) >>> - Target release date (+3 weeks) >>> >>> This would give us 2 more weeks. Note, that we would not put the target >>> release date 2 week later, but put KIP freeze 2 weeks earlier. >>> >>> It does of course not come for free. In particular, having 2 weeks >>> (instead of 1 week) between feature freeze and code freeze implies a >>> longer period when PR needs to be double committed. However, from my >>> personal experience, I don't think that this burden on committers it too >>> high. >>> >>> Looking forward to your feedback. >>> >>> >>> -Matthias >>> >>
