Open Stack

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.

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