On Aug 6, 2014, at 5:10 PM, Michael Still <mi...@stillhq.com> wrote:
> 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. 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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
