Open Stack

On 05/28/2015 12:41 PM, Devananda van der Veen wrote:
> Hi all,
> 
> tl;dr;
> 
> At the summit, the Ironic team discussed the challenges we've had with
> the current release model and came up with some ideas to address them.
> I had a brief follow-up conversation with Doug and Thierry, but I'd
> like this to be discussed more openly and for us (the Ironic dev
> community) to agree on a clear plan before we take action.
> 
> If Ironic moves to a release:independent model, it shouldn't have any
> direct effect on other projects we integrate with -- we will continue
> to follow release:at-6mo-cycle-end -- but our processes for how we get
> there would be different, and that will have an effect on the larger
> community.
> 
> Longer version...
> 
> We captured some notes from our discussion on Thursday afternoon's etherpad:
> https://etherpad.openstack.org/p/liberty-ironic-scaling-the-dev-team
> 
> Which I've summarized below, and mixed in several themes which didn't
> get captured on the 'pad but were discussed somewhere, possibly in a
> hallway or on Friday.
> 
> Current challenges / observations:
> - six weeks' feature freeze is not actually having the desired
> stabilizing effect
> - the post-release/pre-summit slump only makes that worse
> - many folks stop reviewing during this time because they know their
> own features won't land, and instead focus their time downstream
> - this creates pressure to land features which aren't ready, and
> leaves few people to find bugs, write docs, and generally prepare the
> release during this window
> 
> The alternative we discussed:
> - use feature branches for risky / large work, keeping total # of
> branches small, and rebasing them regularly on master
> - keep trunk moving quickly for smaller / less risky / refactoring changes
> - "slow down" for a week or two before a release, but dont actually
> freeze master
> - cut releases when new features are available
> - OpenStack coordinated releases are taken from latest independent release
> - that release will then get backports & stable maintenance, other
> independent releases don't

This sounds very much like what swift has been doing, which seems to
work well.

One thing I'll point out about feature branches - swift does the same
thing - but by "low" what we mean _really_ is "one that tends to have at
least a one-cycle lifespan that represents SIGNIFICANT work" Erasure
Coding was the most recent one.

I mention that because feature branches carry a cost here- but there are
plenty of things on the internets that talk about the awesome things you
can do with them - most of which are ways to work around not actually
having real CI.

In fact, for most risky things I'd suggest a feature flag and landing
the patches into master. However, there are things that involve big
refactors where hiding behind a flag would quickly get bong.

So - sounds great and there is successful prior art - but just be wary
of actually making use of the feature branch - and I counsel always
asking yourself first "is it possible to do this without one" because
the pain will be less.

> We think this will accomplish a few things:
> - make the developer experience better by being more consistent, thus
> keeping developers engaged year-round and increase the likelyhood
> they'll find and fix bugs
> - reduce stress on core reviewers since there's no "crunch time" at
> the end of a cycle
> - allow big changes to "bake" in a feature branch, rather than in a
> series of gerrit patches that need to be continually re-reviewed and
> cherry-picked to test them.
> - allow operators who wish to use Ironic outside of OpenStack to
> consume feature releases more rapidly, while still consuming approved
> releases instead of being forced to deploy from trunk
> 
> 
> For reference, Michael has posted a tracking change to the governance
> repo here: https://review.openstack.org/#/c/185203/
> 
> Before Ironic actually makes the switch, I would like us to discuss
> and document the approach we're going to take more fully, and get
> input from other teams on this approach. Often, the devil is in the
> details - and, for instance, I don't yet understand how we'll fit this
> approach into SemVer, or how this will affect our use of launchpad to
> track features (maybe it means we stop doing that?).
> 
> Input appreciated.
> 
> Thanks,
> Devananda
> 
> __________________________________________________________________________
> 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
>