Open Stack

On 05/28/2015 06: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

Note, that will need some scheduling anyway, so that we can slow down a 
week before. So probably still some milestone process required, wdyt?

> - OpenStack coordinated releases are taken from latest independent release
> - that release will then get backports & stable maintenance, other
> independent releases don't

So no stable branch for other independent releases? What if serious 
security issue is found in one of these? Will we advice users to 
downgrade to the latest coordinated release?

>
> 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?).

I don't see problem with using launchpad tbh.

Re versions my biggest concern is pbr: I don't know how it's version 
detection black magic is going to react if we go from 2015.1 to say 1.0.

>
> 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
>