At the QA meeting today, we discussed the proposal for moving up the Final Freeze by a week. QA agreed that it was acceptable to declare Final Freeze as November 18th instead of November 25th to give us more time to run through Final release validation and find blockers without slipping into - and past - the holidays.
We need FESCo's votes on this ASAP, as we need to communicate this change in schedule urgently.
We also need to talk with the rel-eng and anaconda folks to make sure that they can soak up this change. I'll start doing that immediately.
I'm tentatively in favor but I want to get the rel-eng and anaconda feedback before voting.
From QA meeting: "QA in principle supports moving any or all of Final TC1, Final freeze and Final release date a week earlier on the schedule to provide more time for blocker identification and fixing and less likelihood of a post-Christmas slip"
To clarify it, with Stephen, we still prefer current GA date but we would like to move only pre-GA dates. That means first test compose (TC1) currently planned for Nov 11 (so it would be tomorrow!) and freeze to avoid churn in package set. Moving GA one week earlier would lead us to Thanksgivings week and Go/No-Go right on Nov 27 - it would lead to slip anyway. After Dec 9, we have buffer for one week slip. Then we're in holidays.
There's still an option to slip to January right now but it would lead to mid-January release (as beginning of January could be still considered as holidays time aka many people still out).
FYI, I spoke to the anaconda folks. Brian Lane and David Lehman both seemed to feel that moving up the Freeze date to the 18th would be fine on their end.
And releng would be able to spin the first test compose tomorrow if needed/decided to.
I'm +1 to this plan.
+1
+1, then
releng and I are +1 to making the change. It will mean that we will not be looking at doing things like product.img that came up last week for f21, we really did not have time to do so before without slipping. It does mean that Final will look just like Beta as far as content goes.
Replying to [comment:8 ausil]:
This is unfortunate, but as we were already well into the realm of "making this change is probably going to cause a slip", I was steeling myself to defer that to F22 anyway. So my vote remains that we should Freeze on Nov. 18th.
I'm surprised that the changes as outlined in https://bugzilla.redhat.com/show_bug.cgi?id=1155228#c32 couldn't be made in a week's time, especially if the deliverables in steps (I) and (II) are done in the next couple of days.
+1 to moving the freeze date as proposed
OK, by my count, we have a sufficient number of votes to move ahead with this. I'll send out the following email later today to devel-announce unless anyone would like to make edits:
{{{ Subject: [IMPORTANT] Fedora 21 Schedule Change
== tl;dr Version ==
We are accelerating the Fedora 21 schedule so that we will enter Final Freeze one week earlier than previously described on the schedule page[1]. This means that all fixes intended for inclusion in the Fedora 21 release must be submitted for the stable repository no later than November 17th (so that we have time to do the updates push and build the Release Candidate on November 18th). The Final Release date will remain at December 9th. This essentially means that we are implementing a planned two-week Final Freeze instead of the traditional one- week freeze.
== Why are we doing this? == The Fedora 21 cycle has run considerably beyond its original deadline, primarily due to the massive number of changes that we have been implementing this time around (in particular, the shift to producing three top-tier Products has had a significant impact). Because of the schedule adjustments that took place during the Alpha and Beta phases, we are now looking at an early December release for Fedora 21.
With the Final Release being so close to the December holidays, any delay that occurs at this point puts Fedora at real danger of slipping out of 2014 entirely. To minimize this risk, FESCo has decided (with QA and rel-eng input), that we are going to make a one-time modification to our schedule. The historic cause of slips has been that the time between the start of Freeze and the completion of the release validation has never left enough room in the schedule to fix any blocker issues that come up. By moving up the Freeze, we hope to be able to identify these blockers faster and maintain our curernt planned release date.
We are aware that shortening a schedule puts added strain on our developers, which is why we generally do not do so except at great reluctance. However, the Fedora Updates Policy[2] describes the period between Beta and Final releases thusly: "The branched tree should now be stabilized and prepared for release. Major changes should be avoided during this period." So the shorter time-frame should already be dedicated only to addressing bug-fixes. Most of these can be handled with a release-day update if needed; those that are truly release- blocking will remain so (and will be allowed to be built into the release candidates during the freeze).
[1] https://fedoraproject.org/wiki/Releases/21/Schedule [2] http://fedoraproject.org/wiki/Updates_Policy#Beta_to_Pre_Release }}}
A little bit late, but +1 from me too.
I think it's a good plan, especially if the freeze in the beginning is a little bit softer to still allow critical bug fixes in.
Critical bug fixes are always an option as Blocker or Freeze Exception bugs. I don't think we need to make the Freeze "soft".
Sent to devel-announce, devel and test
I also updated https://fedoraproject.org/wiki/Releases/21/Schedule
Login to comment on this ticket.