Open Stack

Excerpts from Thierry Carrez's message of 2017-12-13 17:17:26 +0100:
> 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


So I want to zero in on this part of the proposal.

It feels like the major driving factor for frustration with the 6 month cadence
is the weight of the coordinated release versus the value, both for developers
and users.

But, I wonder, why do we put so much emphasis on this one process?

One thing I've always admired about Swift was how immune to the cadence Swift
appears to be.

If a set of enthusiastic developers shows up mid-cycle and starts hammering on
a new feature, there's no angst about whether or not it can be done "this
release". It's worked on, Swift moves forward, and when it is done, Swift
releases.

We have this amazing tool that lets us get away with not doing the hard work
Swift did to encapsulate itself. Zuul has enabled us to test all the projects
that want to co-gate together as one. This allows co-dependencies to creep in
under the covers. We have something that, on first look, appears to be
micro-service-architecture, but then in reality, behaves like a massive
monolithic piece of software.

But maybe we're papering over the real problem. Maybe we need to stop working
so hard to coordinate these releases.

As projects mature, I'd expect some to slow down and some to speed up. Glance,
for instance, is in perpetual maintenance mode. Nova is currently in a pretty
heavy debt pay down state and still landing features. Neutron too. So I'd
expect Glance to make frequent small releases of newly fixed items. Nova might
need to do a slower release while a refactor happens, and then a few follow-ups
to get fixes and small enhancements out.

I understand you mentioned the intermediate release tag and practice. I'm
suggesting that we should focus on getting _everyone_ on that train. I don't
think this works without such an effort.

We can keep the release name cadence. But then we get the best of both worlds.
We can take stock of the intermediate releases over the last year, and make
sure they all work together once a year. Chris Jones mentioned that we should
give users time between milestones and release. I suggest we release an
intermediary and _support it_. Let distros pick those up when they need to ship
new features. Let users jump ahead for a few projects when they need the bug
fixes. And then once a year, have a flag day where we all stop, and make an
assertion that we've done some things, achieved some goals, and suggest that
you upgrade all the components to at least that version, and that we'll make
sure you can do that from the last big version.

I understand the belief that nobody will run the intermediaries. If we don't
make them work independently of other projects, nobody will. But if we do, and
if we make sure our interfaces are solid enough to advance components at a
disjoint pace, then users will in fact start to do just that, and we'll retain
the faster feedback cycle, without the heavy community load of coordinated
releases every 6 months.