Open Stack

Dmitry, Ruslan, Mike,
I assume that we agreed on this short plan (thank you all and Thierry
for cooperation). I fully support it.

* Short FF: create stable branch couple of weeks after FF for upstream Fuel
* Untie release schedule for upstream Fuel and MOS. This should be two
separate schedules


Dmitry,
I don't have yet enough context to discuss Fuel 9.0 release but I have
a question about 8.0.

You mentioned that "the start of Fuel 8.0 release cycle inevitably
remains coupled with MOS". Does it mean that we still consider
decoupling for 8.0, just later in the cycle, or we are going to do it
for 9.0?
Regards,
Igor Marnat


On Fri, Aug 28, 2015 at 9:30 AM, Dmitry Borodaenko
<dborodaenko at mirantis.com> wrote:
> 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
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev