Open Stack

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