Open Stack

On 14 December 2017 at 07:09, Nick Barcet <nijaba at redhat.com> wrote:
> Hello Thierry,
>
> Really appreciate the effort you are putting to find creative ways to help
> new contributors join our project.  However, based on my experience, it
> seems that:
> - the longer the delay between the releases, the harder they are to deliver
> - the main problem newcomers may have today, is that the release process is
> very disruptive if they have not completed their feature in time for the
> next cut, and not getting it in time will mean a 6 months delay, which is
> very frustrating.

I agree with these points. I would also add that besides that bigger
releases are hard to deliver, stable branches are harder to maintain
as time goes. By that I mean:
1. bug is submitted
2. bug is fixed in master
3. bug is backported to stable

As time goes discrepancy between master and stable grows and backports
are more expensive. Also it will lower the cadence of "this bug is
fixed by new feature" and could potentially mean users/ops will have
to suffer it for longer time.

> As a consequence, I would rather propose:
> - a longer cadence for stable releases
> - a quicker cadence for intermediary releases (release early, release
> often...)

I agree with that approach. With lightweight releases (but still
releases so some cross-community testing is involved, even if only
automated one) we leave decision to operators to either wait for a
year, upgrade in smaller chunks with some testing or chase master with
nearly no testing.

> A longer cadence for stable release would mean that we pick a duration
> between stable branches that would fit our users' need and that is a
> multiplier of the shorter release.  Based on the interview we conducted on
> our user base a year and a half ago, it seemed that 18mo was the right
> cadence, but we could easily poll the wider OpenStack user base to have
> confirmation.  The justification we got for an 18 month cadence was that it
> was itself a divider of most user hardware life-cycle (3 years) and would
> help in their overall life-cycle management (ie they can decide to upgrade
> their hw once in the duration, or not and get to a new version at hw renewal
> every 3 years).
>
> A quicker cadence for intermediary release would mean that instead of
> creating a branch per release, we would only tag the various project
> branches for a release, validating that integration tests and fixes are
> aligned at this point.  Distributions could independently decide to provide
> these release and create their own branch to maintain those, but this would
> not be the burden of the overall project.   As a consequence of the quicker
> cadence, the integration milestone duration should be reduced to something
> like 2 or 3 weeks.  Switching to tagging a release instead of branching,
> should allow for almost uninterrupted merge request, to the exception of the
> integration period when only integration fixes should be (temporarily)
> accepted, but overall simplifying what one has to do to resume his work from
> one version to another.  Also, with a quicker release cycle, the impact of
> missing the window would be less penalizing, which I believe is a big part
> of the newcomers frustration with the project.  If we were going with
> 18month stable, then 3 month or 1.5 months intermediary releases would be my
> recommendation.
>
> What would that mean for summits? I would think that we could only have one
> "worldwide" summit yearly, with the ability to have regional summits in
> between.
> What would that mean for PTG? I would propose to keep a 6 monthly cadence
> for in person PTG, but formalize the creation of a 3 monthly virtual project
> gathering over a period of 48h.  No cross project topics would happen in
> those.
>
> As a consequence of this I think we would have:
> - a stable branch lifecycle which is more aligned with our user base
> - the ability for fast user to run from master "tagged version"
> - the ability for distros to differentiate on the model the adopt with
> respect to the intermediary release
> - less frustration for newcomers
> - a project that moves faster
>
> Thanks for taking the time to read this proposal.
>
> Nick
>
>
>
> On Wed, Dec 13, 2017 at 11:17 AM, Thierry Carrez <thierry at openstack.org>
> wrote:
>>
>> Hi everyone,
>>
>> Over the past year, it has become pretty obvious to me that our
>> self-imposed rhythm no longer matches our natural pace. It feels like we
>> are always running elections, feature freeze is always just around the
>> corner, we lose too much time to events, and generally the impression
>> that there is less time to get things done. Milestones in the
>> development cycles are mostly useless now as they fly past us too fast.
>> A lot of other people reported that same feeling.
>>
>> As our various components mature, we have less quick-paced feature
>> development going on. As more and more people adopt OpenStack, we are
>> more careful about not breaking them, which takes additional time. The
>> end result is that getting anything done in OpenStack takes more time
>> than it used to, but we have kept our cycle rhythm mostly the same.
>>
>> Our development pace was also designed for fast development in a time
>> where most contributors were full time on OpenStack. But fewer and fewer
>> people have 100% of their time to dedicate to OpenStack upstream
>> development: a lot of us now have composite jobs or have to participate
>> in multiple communities. This is a good thing, and it will only
>> accelerate as more and more OpenStack development becomes fueled
>> directly by OpenStack operators and users.
>>
>> In another thread, John Dickinson suggested that we move to one-year
>> development cycles, and I've been thinking a lot about it. I now think
>> it is actually the right way to reconcile our self-imposed rhythm with
>> the current pace of development, and I would like us to consider
>> switching to year-long development cycles for coordinated releases as
>> soon as possible.
>>
>> What it means:
>>
>> - 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
>>
>> What it does _not_ mean:
>>
>> - It doesn't mean we'd release components less early or less often. Any
>> project that is in feature development or wants to ship changes more
>> often is encouraged to use the cycle-with-intermediary release model and
>> release very early and very often. It just means that the minimum we'd
>> impose for mature components is one release per year instead of one
>> release every 6 months.
>>
>> - It doesn't mean that we encourage slowing down and procrastination.
>> Each project would be able to set its own pace. We'd actually encourage
>> teams to set objectives for the various (now longer) milestones in the
>> cycle, and organize virtual sprints to get specific objectives done as a
>> group. Slowing down the time will likely let us do a better job at
>> organizing the work that is happening within a cycle.
>>
>> - It doesn't mean that teams can only meet in-person once a year.
>> Summits would still provide a venue for team members to have an
>> in-person meeting. I also expect a revival of the team-organized
>> midcycles to replace the second PTG for teams that need or want to meet
>> more often.
>>
>> - It doesn't mean less emphasis on common goals. While we'd set goals
>> only once per year, I hope that having one full year to complete those
>> will let us tackle more ambitious goals, or more of them in parallel.
>>
>> - It doesn't simplify upgrades. The main issue with the pace of
>> upgrading is not the rhythm, it's the imposed timing. Being forced to
>> upgrade every year is only incrementally better than being forced to
>> upgrade every 6 months. The real solution there is better support for
>> skipping releases that don't matter to you, not longer development cycles.

I will argue that it will make upgrades harder. Every feature can
break upgrade - so more features, more chances to break upgrade. Lot
of small steps can be easier to handle than one giant leap.

>> - It doesn't give us LTS. The cost of maintaining branches is not really
>> due to the number of them we need to maintain in parallel, it is due to
>> the age of the oldest one. We might end up being able to support
>> branches for slightly longer as a result of having to maintain less of
>> them in parallel, but we will not support our stable branches for a
>> significantly longer time as a direct result of this change. The real
>> solution here is being discussed by the (still forming) LTS SIG and
>> involves having a group step up to continue to maintain some branches
>> past EOL.
>>
>> Why one year ?
>>
>> Why not switch to 9 months ? Beyond making the math a lot easier, this
>> has mostly to do with events organization. The Summits are already
>> locked for 2018/2019 with a pattern of happening in April/May and
>> October/November. As we want to keep the PTG event as a separate
>> work-focused productive event at the start of every cycle, and not have
>> it collide with one of those already-planned summits, going for a yearly
>> rhythm is the best solution.
>>
>> When ?
>>
>> If we switch, we could either pick February/March or August/September as
>> the start of cycle / yearly PTG time. From an events organization
>> perspective, it is a lot easier to organize a week-long event in
>> February/March. August is a no-go for a lot of the world. Early
>> September is a mess with various US and religious holidays. Late
>> September is just too close to the October/November summit.
>>
>> So the year-long cycles would ideally start at the beginning of the
>> year, when we would organize the yearly PTG. That said, I'm not sure we
>> can really afford to keep the current rhythm for one more year before
>> 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).
>>
>> Who makes the call ?
>>
>> While traditionally the release team has been deciding the exact shape
>> of development cycles, we think that this significant change goes well
>> beyond the release team and needs to be discussed across all of the
>> OpenStack community, with a final decision made by the Technical
>> Committee.
>>
>> So... What do you think ?
>>
>> --
>> Thierry Carrez (ttx)
>>
>> __________________________________________________________________________
>> 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
>
>
>
>
> --
> Nick Barcet - Senior Director Product Management - OpenStack
> nijaba at redhat.com | +1 (978) 392 2482 | @nijaba
>
> __________________________________________________________________________
> 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
>