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 >> >
