Open Stack

Hey everyone,

There was some discussion about this in the operator community, so I just
wanted to make sure folks were aware of this recap that Thierry did. I think it
nicely captures and summarizes some of the issues brought up in the long thread
in openstack-dev.

Thanks,
Sean

----- Forwarded message from Thierry Carrez <thierry at openstack.org> -----

Date: Mon, 18 Dec 2017 15:08:45 +0100
From: Thierry Carrez <thierry at openstack.org>
To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [all] TL;DR: Switching to longer dev cycles ?
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0

A lot of people chose to stay away from the 118-message long thread and
wish there was a summary of it and the discussions on IRC around it.

Mike posted one on the -dev digest:

https://www.openstack.org/blog/2017/12/developer-mailing-list-digest-december-9-15th/

Here is my try at summarizing, in hope it will be helpful.

First, you should read the initial proposal at:

http://lists.openstack.org/pipermail/openstack-dev/2017-December/125473.html


Most of the +1s appear to come from people that would welcome less of a
"taxing treadmill" (in jgriffith's words). A significant share of them
are in the packaging space, where the quantity of work is more directly
correlated to the release cadence.


A lot of objections were posted on the ML or on IRC (and for the record,
I agree with most of them):

1/ Treating the symptom rather than underlying cause

While increasing overall cycle length would ease the pain resulting from
a number of issues, it does not directly treat the underlying causes,
and it has other consequences that may not be as beneficial. The most
obvious of those being that we'd get less done overall, due to having
less forced rhythm/deadlines.

2/ Nobody would consume intermediary releases, resulting in longer
feedback loops

The proposal encourages releasing intermediary releases more often, as a
way to keep releasing early and often. However, for most projects, users
would likely wait for the "real" releases (those with proper feature
freezes, stabilization period and stable branches for post-release
bugfixes) rather than use the intermediaries. This would likely result
in a deteriorated longer feedback loop, with devs waiting up to one year
to get real-world usage / bugs on a feature they just added. So 6-month
"real" releases might still be the right sweet spot between what we can
deliver and a reasonable feedback loop length.

3/ The change would not simplify the life of part-time contributors

The main driver for the proposal is to make OpenStack development more
doable by people who can only spend 20% of their work time on OpenStack
upstream development, as our current pace can be overwhelming. However,
most of the difficulty to keep up is linked to change velocity, and
change velocity is not directly driven by cycle length, so it may stay
mostly the same. If a change is too big to land in 6-month work by a
part-time contributor, it can be split. And if a change misses the boat,
it's a one-year wait rather than a 6-month one.

4/ The overhead of cycle events is not that overwhelming

One goal of the proposal is to reduce the amount of time spent in a year
around development cycle events and process (PTL election, PTG
preparation, feature freeze, release process...) in order to get some
extra time back. Some objected that these don't take that much time,
that feature freeze or PTG prep are actually good things to do, or that
boilerplate can be reconsidered without lengthening the cycle. We could,
for example, only run one PTL election per year without increasing the
dev cycle length.

5/ Most issues that the proposal aims to solve can be solved with better
project management

Getting more realistic at planning the work that can get done within a
cycle would go a long way to make people feel better about the available
time they have. Actively engaging with part-time contributors and making
them feel welcome and valuable would probably drive more direct results
than an extrinsic change like increasing the cycle length. This may
point to the need to spend more time together in a productive
environment like the PTG rather than less.

6/ Larger events are easier to justify and get to

For a number of people it is easier to justify traveling to PTGs than to
smaller midcycles team meetups. Removing one PTG might therefore limit
valuable face-to-face time for team members. It would definitely reduce
the amount of time we spend on cross-project collaboration.

7/ Focus on the real solutions

Fast-forward upgrades (and supporting selected branches past their end
of life) are the real solutions for helping users and vendors keep up
with the rate of releases, not making less of them. We should focus on
that, and the proposal might actually make that more difficult (or a
longer endeavor). We could also try to make releases cycles less of a
"taxing treadmill" by removing as much boilerplate as possible within a
cycle and implementing other low-hanging fruit changes.


I hope I captured most of the objections. If you feel like one of the
objections was not mentioned (or not adequately represented), please add
to this thread :)

-- 
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

----- End forwarded message -----