Thanks for this, Matthias! I’m in favor. I’m glad we have all been working hard to stabilize our releases and offer a high quality project, even if it means delays. However, the last several releases have demonstrated that we consistently need more time than we have allocated. Rather than risk building an expectation that our releases will always be delayed, we should just move up the deadlines.
Thanks, John On Tue, Sep 29, 2020, at 21:29, Matthias J. Sax 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 >
