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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev