Open Stack

On Oct 11, 2013, at 17:17 , Russell Bryant <rbryant at redhat.com<mailto:rbryant at redhat.com>>
 wrote:

On 10/11/2013 09:02 AM, Alessandro Pilotti wrote:
OpenStack is organized differently: there are lots of separate projects (Nova, Neutrom, Glance, etc) instead of a single one (which is a good thing), but I believe that a similar approach can be applied. Specific contributors can be nominated "core rewievers" on specific directories in the tree only and that would scale immediately the core review bandwidth.

As a practical example for Nova: in our case that would simply include the following subtrees: "nova/virt/hyperv" and "nova/tests/virt/hyperv". Other projects didn't hit the review bandwidth limits yet as heavily as Nova did, but the same concept could be applied everywhere.

If maintainers of a particular driver would prefer this sort of
autonomy, I'd rather look at creating new repositories.  I'm completely
open to going that route on a per-driver basis.  Thoughts?

Well, as long as it is an official project this would make definitely sense, at least for Hyper-V.
Stability of the driver's interface has never been a particular issue to prevent this to happen IMO.
We should think about how to handle the testing, considering that we are getting ready with the CI gate.

For the main tree, I think we already do something like this in
practice.  Core reviewers look for feedback (+1/-1) from experts of that
code and take it heavily into account when doing the review.


There's only one "small" issue with the current approach.

Current reviews require:

+1 "de facto" driver X mantainer(s)
+2  core reviewer
+2A  core reviewer

While with the proposed scenario we'd get to a way faster route:

+2  driver X mantainer
+2A another driver X mantainer or a core reviewer

This would make a big difference in terms of review time.

Thanks,

Alessandro


--
Russell Bryant

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131011/53ba9d4f/attachment.html>