Open Stack

> On May 28, 2015, at 9:54 AM, Monty Taylor <mordred at inaugust.com> wrote:
> 
> 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.

I affirm what Monty says here. The feature branches that we've used in Swift have been for significant efforts that cut across large parts of the codebase and span more than one openstack cycle. The ones we've used so far are for storage policies (1 year) and erasure codes (9 months), and we've currently got two: one for encryption (about 4 months so far) and the newest is for the golang object server.

While I like the feature branches, I'd recommend only using them as necessary for very large efforts. If you do, then I'm happy to share what has and hasn't worked for us over the last 24-30 months of using them.


Overall, I'm thrilled to see Ironic's new plan for releases.


--John




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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150528/41741043/attachment.pgp>