Open Stack

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