On Thursday, May 28, 2015, Devananda van der Veen <devananda....@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
__________________________________________________________________________ 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
