Open Stack

On Thursday, May 28, 2015, Devananda van der Veen <devananda.vdv at gmail.com>
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
>
> 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
>
>
I am looking forward to see how this transition works for Ironic and how it
could apply to other projects.

This sounds like a great approach!

--Morgan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150528/2fe0acc5/attachment.html>