Team, With Fuel 8.0 Soft Code Freeze approaching, it's time to switch to the new branching strategy and implement the plan to align Fuel releases with OpenStack release cycles that we have discussed back in August [0].
[0] http://lists.openstack.org/pipermail/openstack-dev/2015-August/073110.html I have updated the 9.0 release schedule [1] and our definitions of Soft Code Freeze [2] and Hard Code Freeze [3] in line with this plan. [1] https://wiki.openstack.org/wiki/Fuel/9.0_Release_Schedule [2] https://wiki.openstack.org/wiki/Fuel/Soft_Code_Freeze [3] https://wiki.openstack.org/wiki/Fuel/Hard_Code_Freeze TL;DR: Dec 23: 8.0 SCF, stable/8.0, development of 9.0 begins Mar 2: 9.0 FF (same time as Mitaka FF) Mar 16: 9.0 SCF, stable/mitaka, development of 10.0 begins Apr 6: 9.0 Release (same time as Mitaka Release) Apr 27--Jun 29: 9.0.1 HCF, 9.0.1 Stable Release Here is how it is going to work. 8.0 Soft Code Freeze -------------------- First things first: Soft Code Freeze is a time-based milestone, for Fuel 8.0 it's scheduled to December 23 and that's precisely when it's going to happen. This time, it's not just the time to focus on High and Critical severity bugs, it is also the time when we create stable/8.0 branches in all Fuel git repositories. We want to do that at SCF instead of HCF so that the period while master branches are closed for feature work is shorter and more predictable. We want to start working on Mitaka support and on Fuel 9.0 features sooner, that's the only way we can adjust our release cycle to catch up with OpenStack. To make sure that Infra team doesn't have to spend Christmas setting up branches and CI jobs, I want to announce the freeze as soon as the clock hits 00:01 MSK. If you have a Medium or lower severity bug that you want to fix in Fuel 8.0, Tuesday 12/22 is your last chance, after that they all go to 9.0. Once SCF is announced, core reviewers are not allowed to merge any commits to any Fuel git repositories until Fuel Infra team has confirmed that they're done creating the stable/8.0 branches and enabling CI jobs for them. When stable/8.0 is up, remember to follow our backporting policy [4]: merge to master first, only then backport the bugfix to stable branches. [4] https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Backport_bugfixes_to_stable_release_series 9.0 Feature Freeze ------------------ If you look carefully at the 9.0 schedule, you will see that it's even shorter than what I proposed in August: instead of reducing the gap between Fuel and OpenStack release milestones, this schedule eliminates it altogether. Starting from Feature Freeze, Fuel 9.0 follows Mitaka milestones. It still leaves us 10 weeks between December 23 and March 2 for feature development (for comparison, in 8.0 we had 9 weeks), but this time, we have a much larger overlap between development and bugfixing: 9.0 FF is only a week after the planned 8.0 release date. We'll need to carefully balance the time of developers and QA engineers between 8.0 and 9.0 activities. For example, just as we can't afford to stop fixing bugs for 8.0 as we design and implement new features for 9.0, we also can't afford to postpone covering new 9.0 features with automated tests while QA engineers are busy with 8.0 acceptance testing. Between this consideration and the fact that we're starting 9.0/mitaka development when OpenStack itself is already halfway through its Mitaka feature development stage, we really can't afford to postpone [5] design and development of any 9.0 features. [5] http://lists.openstack.org/pipermail/openstack-dev/2015-December/082340.html I don't believe backporting bug fixes from master to stable/8.0 over larger number of feature commits is going to significantly slow down our bugfixing work. 90% of the bugfixing effort is investigation and root cause analysis, and only 10% is writing the code for the fix. And even with that last 10%, we didn't have to rewrite most of the patches that we backported across several stable releases, so backporting over a few weeks worth of changes is not going to be that much of an overhead. To reiterate, we need to identify our top priority 9.0 features by December 23, and should start merging them as soon as master branch is open. 9.0 Soft Code Freeze -------------------- When the rest of OpenStack publishes RC1s and creates stable/mitaka branches around March 16, so do we. Starting with 10.0, we'll have a full 6-month release cycle with the same milestones as OpenStack N. And by the N summit in Austin in April, we'll have spent enough time planning and designing Fuel 10.0 features to come to the summit with a good idea of what we want to discuss with other OpenStack projects, and to return from the summit with solid cross-project collaboration plans. 9.0.x Releases -------------- Finally, the biggest difference from Fuel 8.0 is going to be in how we handle the release. We postpone the quality-based HCF milestone and the full acceptance testing until after the initial 9.0 release. Instead, we do what OpenStack does: keep improving automatic test coverage, keep the CI green through all stages of the release cycle, and iterate through several RCs for a couple of weeks until we get one that doesn't have Critical bugs. This will give us a release that is not as well tested as what we're used to, which is not as bad as it sounds: we trade off some level of confidence in quality for something equally important -- timeliness. Releasing Fuel 9.0 together with Mitaka will enable early adopters to deploy and evaluate Mitaka as soon as it is out. The feedback from these early adopters is going to be at least as valuable as an extra cycle of acceptance testing, and will allow us to proceed from the time-based to the quality-based part of our release cycle. At that point, we test, we gather feedback, we fix more bugs, until we meet the Hard Code Freeze entry criteria. We iterate through a couple more RCs and, when one of them passes our acceptance testing, we publish a stable point version: Fuel 9.0.1. Earliest we can possibly do that is May 18, although realistically it's going to be longer than that, in the worst case I expect we'll be able reach HCF on June 8 and release 9.0.1 on June 29. External Dependencies --------------------- The biggest risk with this plan is the external dependencies. We need OpenStack components to remain compatible with the Fuel reference architecture. We need Puppet OpenStack modules which we reuse in Fuel Library to become stable no later than around mitaka-3. For that, Puppet OpenStack itself needs stable rpm and deb packages of OpenStack components and their dependencies at least by mitaka-2. None of the above will happen without our active involvement and close collaboration with other OpenStack projects. Lets plan for it, and lets get it done. -- Dmitry Borodaenko __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
