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 P
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,
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, 20
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
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 i
