Open Stack

> On Dec 13, 2017, at 6:44 PM, Clint Byrum <clint at fewbar.com> wrote:
> 
> 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.

What would our world look like if we treated inter-service dependencies like 
we do service-to-library dependencies and only integration test released 
components, rather than installing everything from source by default?

Doug