On 09/10/2014 04:11 PM, Jay Pipes wrote:
On 09/10/2014 05:55 PM, Chris Friesen wrote:
If each hypervisor team mostly only modifies their own code, why would
there be conflict?
As I see it, the only causes for conflict would be in the shared code,
and you'd still need to sort out the issues with the shared code even if
you split out the individual drivers into separate repos.
a) Sorting out the common code is already accounted for in Dan B's
original proposal -- it's a prerequisite for the split.
Fair enough.
b) The conflict Dan is speaking of is around the current situation where
we have a limited core review team bandwidth and we have to pick and
choose which virt driver-specific features we will review. This leads to
bad feelings and conflict.
Why does the core review team need to review virt driver-specific stuff.
If we're looking at making subteams responsible for the libvirt code
then it really doesn't matter where the code resides as long as everyone
knows who owns it.
c) It's the impact to the CI and testing load that I see being the
biggest benefit to the split-out driver repos. Patches proposed to the
XenAPI driver shouldn't have the Hyper-V CI tests run against the patch.
Likewise, running libvirt unit tests in the VMWare driver repo doesn't
make a whole lot of sense, and all of these tests add a
not-insignificant load to the overall upstream and external CI systems.
The long wait time for tests to come back means contributors get
frustrated, since many reviewers tend to wait until Jenkins returns some
result before they review. All of this leads to increased conflict that
would be somewhat ameliorated by having separate code repos for the virt
drivers.
Has anyone considered making the CI tools smarter? Maybe have a way to
determine which tests to run based on the code being modified?
If someone makes a change in nova/virt/libvirt there's a limited set of
tests that make sense to run...there's no need to run xen/hyperv/vmware
CI tests against it, for example. Similarly, there's no need to run all
the nova-scheduler, neutron, server groups, etc. tests.
That way we could give a subteam real responsibility for a specific area
of the code, and submissions to that area of the code would not be gated
by bugs in unrelated areas of the code.
Chris
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
