Open Stack

Thanks everyone for the feedback!

There weren't any comments about options (1) and (4), I'm interpreting
it as a consensus that we're not doing a "future" branch, and as a sign
that nobody wants to even think about CI for external forks (which I'm
sure will come back to haunt us, so don't count on not having to think
about it for long).

With the two extremes out of the way, and taking into account comments
from Thierry, Igor, Ruslan, and Mike, here's a first draft of how
exactly we can switch to the new model.

1) 7.0 hard code freeze -- September 3

Assuming that Earth remains in orbit and Fuel 7.0 hard code freeze
doesn't slip, on September 3 we will create stable/8.0 branches for all
Fuel components, and open master branch for feature development. From
day 1, we will be targeting Liberty, so this time creating parallel CI
jobs sets (8.0 and 8.0-kilo) will be done as part of 7.0 HCF. As soon as
8.0 becomes consistently green, 8.0-kilo will be discarded.

One of the first things to do in Fuel 8.0 is finish the conversion of
fuel-library to librarian for integration of upstream Puppet OpenStack,
and conversion of MOS packaging to upstream rpm and deb packaging
projects. Starting late relative to OpenStack milestones will allow us
to use a relatively stable base for these conversions.

2) 8.0 feature freeze -- December 10 (approximate)

Since we already had a long feature freeze in 7.0, the start of Fuel 8.0
release cycle inevitably remains coupled with MOS. Squeezing the rest of
the cycle before Liberty release on October 15 would make it absurdly
short, lets not do that. So no need for a downstream branch just yet.

What we can do instead is use the short feature freeze in 8.0 to start
working on Mitaka based Fuel 9.0 much earlier in the cycle, and gain
enough time to shift the 9.0 release schedule.

3) 8.0 soft code freeze -- December 24 (approximate)

Around December 24, we will create stable/8.0 branches, open master
branch for feature development and target it at Mitaka (by that time it
should be mitaka-1), following the same process as 7.0 HCF: create
parallel CI job sets 9.0 and 9.0-liberty.

This will give us enough time to design and implement Fuel 9.0 features
by Mitaka feature freeze (based on Kilo schedule, around March 17), even
accounting for having to divide attention between:

  a) fixing High & Critical bugs in stable/8.0
  b) fixing Medium & lower bugs in master
  c) implementing 9.0 features in master
  d) Christmas and New Year

4) 8.0 hard code freeze -- February 4 (approximate)

After 8.0 HCF, features for 9.0 become the primary focus.

5) 9.0 feature freeze -- April 14 (approximate)

Some Fuel features may be blocked or regressed by OpenStack feature
commits [*], we'll need at least 2 weeks after upstream FF to finalize
them and get them through review and CI, and, just for 9.0, 2 more weeks
for unforseen risks since we'll be doing it this way for the first time.

[*] With the conversion to upstream packaging and puppet code completed
    during 8.0 cycle, in 9.0 Fuel's bugfixing will depend on stability
    of these upstream projects.

    In Kilo, deb packaging took about a month to stabilize (April 30 to
    June 3), and puppet took another month (July 9). In Liberty,
    packaging and puppet are better aligned with OpenStack schedule and
    with each other, I think it's reasonable to expect that by Mitaka
    the lag for all 4 projects (deb, rpm, puppet, fuel) will be the same
    2 weeks after OpenStack release instead of 2 months.

6) 9.0 soft code freeze -- April 28 (approximate)

Same 2 weeks for dealing with feature merge fest fallout on the master
branch before opening it for feature work for the nest release. Same
stable branch and parallel stable/master CI dance as with 8.0, except
this time we should probably call the new branch stable/mitaka.

7) 9.0 hard code freeze -- May 26 (approximate)

And this is how we can get the first release candidate of
Mitaka-compatible Fuel only 4 weeks after Mitaka Release.

8) 9.0-based downstream branch

At some point after Fuel 9.0 SCF, a vendor can decide that their
distribution needs some bugfixes that were not accepted for
stable/mitaka in community Fuel, or even some features that missed the
feature freeze.

This is where a downstream branch in a repository hosted outside of
OpenStack Infra comes in. The considerations of pure-play contribution,
early community review, not spawning a proprietary fork, and not killing
puppies, dictate that they propose to community master before
backporting to downstream stable. Still, if someone decides that they
really hate puppies, Apache License provides enough rope to deal with a
fully closed and incrementally diverging fork.

This plan is too detailed and elaborate to work out exactly as laid out,
but I think it's achievable. Lets see if there's anything that we know
can't work the way I described, and what kinds of decisions we need to
make now or be prepared to make as we try to reconcile this plan with
reality.

-- 
Dmitry Borodaenko