On 09/12/2014 04:59 PM, Joe Gordon wrote:
On Thu, Sep 11, 2014 at 2:18 AM, Daniel P. Berrange <[email protected]
<mailto:[email protected]>> wrote:
FYI, for Juno at least I really don't consider that even the libvirt
driver got acceptable review times in any sense. The pain of waiting
for reviews in libvirt code I've submitted this cycle is what prompted
me to start this thread. All the virt drivers are suffering way more
than they should be, but those without core team representation suffer
Can't you replace the word 'libvirt code' with 'nova code' and this
would still be true? Do you think landing virt driver code is harder
then landing non virt driver code? If so do you have any numbers to back
this up?
If the issue here is 'landing code in nova is too painful', then we
should discuss solving that more generalized issue first, and maybe we
conclude that pulling out the virt drivers gets us the most bang for our
buck. But unless we have that more general discussion, saying the right
fix for that is to spend a large amount of time working specifically on
virt driver related issues seems premature.
I agree that this is a nova issue in general, though I suspect that the
virt drivers have quite separate developer communities so maybe they
feel the pain more clearly. But I think the solution is the same in
both cases:
1) Allow people to be responsible for a subset of the nova code
(scheduler, virt, conductor, compute, or even just a single driver).
They would have significant responsibility for that area of the code.
This would serve several purposes--people with deep domain-specific
knowledge would be able to review code that touches that domain, and it
would free up the nova core team to look at the higher-level picture.
For changes that cross domains, the people from the relevant domains
would need to be involved.
2) Modify the gate tests such that changes that are wholly contained
within a single area of code are not blocked by gate-blocking-bugs in
unrelated areas of the code.
Chris
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
