On 09/10/2014 05:55 PM, Chris Friesen wrote:
On 09/10/2014 02:44 AM, Daniel P. Berrange wrote:
On Tue, Sep 09, 2014 at 05:14:43PM -0700, Stefano Maffulli wrote:
I have the impression this idea has been circling around for a while but
for some reason or another (like lack of capabilities in gerrit and
other reasons) we never tried to implement it. Maybe it's time to think
about an implementation. We have been thinking about mentors
https://wiki.openstack.org/wiki/Mentors, maybe that's a way to go?
Sub-team with +1.5 scoring capabilities?
I think that setting up subteams is neccessary to stop us imploding but
I don't think it is enough. As long as we have one repo we're forever
going to have conflict & contention in deciding which features to accept,
which is a big factor in problems today.
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.
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.
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
OpenStack-dev mailing list