Open Stack

On Aug 6, 2014, at 5:10 PM, Michael Still <mikal at stillhq.com> wrote:

> On Wed, Aug 6, 2014 at 2:03 AM, Thierry Carrez <thierry at openstack.org> wrote:
> 
>> We seem to be unable to address some key issues in the software we
>> produce, and part of it is due to strategic contributors (and core
>> reviewers) being overwhelmed just trying to stay afloat of what's
>> happening. For such projects, is it time for a pause ? Is it time to
>> define key cycle goals and defer everything else ?
> 
> The nova team has been thinking about these issues recently too --
> especially at our mid cycle meetup last week. We are drawing similar
> conclusions to be honest.
> 
> Two nova cores were going to go away and write up a proposal for how
> nova could handle a more focussed attempt to land code in Kilo, but
> they haven't had a chance to do that yet. To keep this conversation
> rolling, here's a quick summary of what they proposed:
> 
> - we rate limit the total number of blueprints under code review at
> any one time to a fixed number of "slots". I secretly prefer the term
> "runway", so I am going to use that for the rest of this email. A
> suggested initial number of runways was proposed at ten.
> 
> - the development process would be much like juno for a blueprint --
> you propose a spec, get it approved, write some code, and then you
> request a runway to land the code in. Depending on your relative
> priority compared to other code attempting to land, you queue until
> traffic control assigns you a runway.
> 
> - code occupying a runway gets nova core review attention, with the
> expectation of fast iteration. If we find a blueprint has stalled in a
> runway, it is removed and put back onto the queue based on its
> priority (you don't get punished for being bumped).
> 
> This proposal is limiting the number of simultaneous proposals a core
> needs to track, not the total number landed. The expectation is that
> the time taken on a runway is short, and then someone else will occupy
> it. Its mostly about focus -- instead of doing 100 core reviews on 100
> patches so they never land, trying to do those reviews on the 10
> patches so they all land.

I’ve been trying to highlight “review priorities” each week in the Oslo meeting, with moderate success. Our load is a lot lower than nova’s, but so is our review team. Perhaps having a more explicit cap on new feature work like this would work better.

I’m looking forward to seeing what you come up with as an approach.

Doug

> 
> We also talked about tweaking the ratio of "tech debt" runways vs
> 'feature" runways. So, perhaps every second release is focussed on
> burning down tech debt and stability, whilst the others are focussed
> on adding features. I would suggest if we do such a thing, Kilo should
> be a "stability' release.
> 
> Michael
> 
> -- 
> Rackspace Australia
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev