On 09/04/2014 07:22 PM, Michael Still wrote: > On Thu, Sep 4, 2014 at 5:24 AM, Daniel P. Berrange <berra...@redhat.com> > wrote: > > [Heavy snipping because of length] > >> The radical (?) solution to the nova core team bottleneck is thus to >> follow this lead and split the nova virt drivers out into separate >> projects and delegate their maintainence to new dedicated teams. >> >> - Nova becomes the home for the public APIs, RPC system, database >> persistent and the glue that ties all this together with the >> virt driver API. >> >> - Each virt driver project gets its own core team and is responsible >> for dealing with review, merge & release of their codebase. > > I think this is the crux of the matter. We're not doing a great job of > landing code at the moment, because we can't keep up with the review > workload. > > So far we've had two proposals mooted: > > - slots / runways, where we try to rate limit the number of things > we're trying to review at once to maintain focus > - splitting all the virt drivers out of the nova tree > > Splitting the drivers out of the nova tree does come at a cost -- we'd > need to stabilise and probably version the hypervisor driver > interface, and that will encourage more "out of tree" drivers, which > are things we haven't historically wanted to do. If we did this split, > I think we need to acknowledge that we are changing policy there. It > also means that nova-core wouldn't be the ones holding the quality bar > for hypervisor drivers any more, I guess this would open the door for > drivers to more actively compete on the quality of their > implementations, which might be a good thing. > > Both of these have interesting aspects, and I agree we need to do > _something_. I do wonder if there is a hybrid approach as well though. > For example, could we implement some sort of more formal lieutenant > system for drivers? We've talked about it in the past but never been > able to express how it would work in practise. > > The last few days have been interesting as I watch FFEs come through. > People post explaining their feature, its importance, and the risk > associated with it. Three cores sign on for review. All of the ones > I've looked at have received active review since being posted. Would > it be bonkers to declare nova to be in "permanent feature freeze"? If > we could maintain the level of focus we see now, then we'd be getting > heaps more done that before.
Agreed. Honestly, this has been a really nice flow. I'd love to figure out what part of this focus is capturable for normal cadence. This realistically is what I was hoping slots would provide, because I feel like we actually move really fast when we call out 5-10 things to go look at this week. -Sean -- Sean Dague http://dague.net _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev