> On Dec 13, 2017, at 6:44 PM, Clint Byrum <cl...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev