Open Stack

On Wed, Dec 13, 2017 at 4:17 PM, 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.
>
> - 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

Give or take week ago when I did read this mail first time, my first
impression was "are you out of your mind". After digesting it for few
days and reading all the other list discussions I start to understand
where this is actually trying to hit and instead think that this is
just yet another wrong conclusion/decision we're going to make to
address real issues. This mail is going to be long, please, bear with
me.

First of all, personally this sounds great. I can travel only one or
two times per year to OpenStack event instead of four atm. (PTG and
maybe one summit, I don't see anyone attending to that midcycle
summit) and I have more time for other things as our pace of movement
will be even slower.

Then starts the problems:
    1) Planning becomes even more difficult. Now we need to predict
future for 4-6months, that will change to predicting future for 10-12
months. This is specially a problem thinking downstream. Now for
reasonable community priorities aligned RFE from product
folks/customers we quite often can provide something to work around
their issues on the next release and something actually productable in
couple. This will move the timeline from 4-12 months to 10-24 months
for lots of real customer discussions, this is not going to cut it.
The other option is that we leave "enough" room to our development
plans to accept specs for these cases, lets say about 8 months into
the dev cycle and the unfortunate person who comes and wants to start
contributing on month 9 gets told that we happily take them on board
but first real release their work will be on is 15 months away. I
don't see this increasing our chances to attract new contributors as
already the about 10 month window they might hit nowadays is turning
lots of them away.
    2) The release rush is already heavy every six months. Now taking
10 months of work into that rush and we're in deep shit. I don't see
any team standing on "if this planned feature will not land by
milestone 1 it's out to the next cycle as our rest milestones are
fully planned", just don't see this happening so it's even easier to
slip certain things forward without that definite cut-off date in
quite near future.
    3) Most likely projects like Glance needs to drop the
follows-stable-policy tag as pushing against backports is already hard
enough in 6 month dev cycle. One release a year, there definitely will
be stuff that needs to be backported due to the external pressure. The
other option would be to drop out from Integrated releases to not
being tied into such long cycles.
    4) Like others have mentioned already i do not see other than
negative impact to those 20% contributors trying to keep up on year of
cycle rather than 6 months. Yes it will likely slow down for the first
6 months of the cycle and the last 6 months rush when everyone is
panicing will be even harder for that one day a week guy. On top of
the fact that the un-prioritized work might still not land to the
release and now it's the wait of next 12 months before it has a
chance.
    5) the upgrade step will not be double but somewhat bigger so this
will not encourage people to upgrade any more than they do now.

So how did we stay alive through 2017 in Glance?

We took the reality into account. We have been planning our dev work
categorized few different ways:
    1) Urgent work that _needs_ to happen this cycle.
    2) Easy stuff that can be done in this cycle with the staff we have.
    3) Bigger features are deemed to take multiple releases already on
the planning/prioritizing phase.
    4) Stranglers that are worked on but miss the deadline are
automatically moved to next cycle instead of having to
renegotiate/re-approve
    5) Un-targeted specs that are effectively RFEs that does not have
anyone committed to get them done on any specific timeline, but seems
like a good idea.
This has given us enough leverage to be more flexible towards people
who can't commit all their time to development/single project without
increasing the paper pushing overhead the spec process has caused. The
Un-tageted specs also provides a good idea for possible new
contributor what they could work on and make impact without being
under pressure from day one and what kind of direction the community
would like to see the project moving.

What comes to the elections, I can see the benefit for extending the
terms. It gives quite a bit more continuity for the project having for
example PTL serving per default more than a cycle (I think that's the
case in most of the projects anyways) and we already are in place
where the PTL can be changed mid term if the personal situation needs
such. This however does/should not need to be coupled with longer
release cycle. But definitely worthy discussion to have I haven't seen
many in the thread jumping on. I guess looking how few of the position
have lately gone into election anyways instead of having only one
candidate, it might not be the biggest issue here. Still definitely
would give bit more continuation and ease the things to remember if
this was done only on yearly basis.

I think starting this discussion at mid December proposing that it
just gets hammered down really quick without anyone noticing before
it's too late and taking effect already from February (with the full
blast holiday season and Q-2,Q-3 panic) is just bad judgment and I'm
fully assuming this wasn't the intention ;)

The one (personally would even prefer this is none) set of community
goals per year is amazing part of this proposal. Again I think it
should not be coupled with release cycle change but lets make it bit
more flexible and easier to plan into the future work.

I'd personally like to counter propose the opposite approach to this issue.

Let's move to 3, 4 month cycles per year and shorten the
freeze/release lock up times. on top of that we should give up the
milestone releases as it has became pretty clear that about everyone
are ignoring them already.
Benefits for doing so to 1 year cycle proposal:
    1) Shortening the wait time for the new contributors to make
impact gives more encouragement to stay in touch and jump in Now
rather than trying to align to the point of when the impact can be
made and possibly doing something else instead that eats their time in
future and keeps them away from OpenStack.
    2) Less pressure from downstream to have it now or backported as
the next release is not so far away.
    3) More or less forces to move away from planning features for one
specific release cycle like we have already seen the benefits in
Glance. Gives more relaxed environment to work on new features.
    4) Less freeze pressure and rush at the end of the cycle as there
is less to release/the rush gets spread out.
    5) More stable releases with less changes to cover and test.
    4) smaller increments makes the upgrades less painful, with fast
forward upgrades already in focus just more versions shouldn't be that
big of an issue.

Caveats that would make it suboptimal:
    1) Would not be sustainable having 6 events (3 PTG and 3 Summits)
per year. TBH I don't see sustainable having 3 of either one as the
current total of 4 already sucks badly. Perhaps this should focus on
keeping two summits with dev meetups and forum together for
geolocation alternation purposes and not pretending to focus on single
release in the Summit. And the design sessions could focus on the
bigger longer running plans rather than nitpicking the wording of the
documentation 90% of the room wasting their time in there.
    2) Downstream would need to package more without clear benefit for
them, other than healthier upstream releases/community. On the other
side some downstream packagers could get fresher versions if their
release times are not aligned/mandated by OpenStack releases.
    3) Even more work to the release and infra teams
    4) Maybe more need for bugfix backports as more branches would
need to be covered.


If you got all the way down here, thanks for reading!

- Erno (jokke) Kuvaja