[openstack-dev] [all] Switching to longer development cycles
dirk at dmllr.de
Wed Dec 13 18:12:26 UTC 2017
2017-12-13 17:17 GMT+01:00 Thierry Carrez <thierry at openstack.org>:
> - We'd only do one *coordinated* release of the OpenStack components per
> year, and maintain one stable branch per year
> - We'd elect PTLs for one year instead of every 6 months
> - We'd only have one set of community goals per year
> - We'd have only one PTG with all teams each year
Well, I assume there would still be a chance to have a mid-cycle PTG
independent of the 1 year release schedule proposal if there
is a need for it.
>From a vendors (downstream) opinion I like the idea of lengthening the
release cycle because
it pushes two major friction points we have with upstream into the community:
* Tracking+fixing all the issues hitting by skipping over the interim
release (FFU/Skip level upgrade). In the past
that was many months of work, hoping of course that the work on FFU
makes this more palatable.
* The joy of having to cherry-picking a feature of the interim release
had and $somebody really absolutely wants, and
then maintain that (and handle all regressions by yourself)
>From an upstream perspective a longer release cycle could potentially
mean a larger "open span" of development where
new features are land and a longer stabilisation period. The tradeoff
is that the window of change and the window of
stabilisation being separated, meaning that we end up with a unplanned
longer period of freeze or with a bad release.
> switching. That is why I'd like us to consider taking the plunge and
> just doing it for *Rocky*, and have a single PTG in 2018 (in Dublin).
+1 Sounds good to me. The only alternative I see is having a different
cycle in the range of 7-11 months (pick a number!) which
causes the release time to always shift to a different month of the
year. 12 months does feel a bit long, but then again it usually
passes by pretty quickly in retrospective.
More information about the OpenStack-dev