On Wed, Aug 6, 2014 at 2:03 AM, Thierry Carrez <thie...@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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev