Open Stack

This is a much needed change. It will ease the effort required by operators
to maintain a current openstack environment.

+1 from me

Chris Krelle



On Dec 13, 2017 8: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.

- 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171213/516039a9/attachment.html>