On Oct 11, 2013, at 18:02 , Russell Bryant <rbry...@redhat.com> wrote:
> On 10/11/2013 10:41 AM, Alessandro Pilotti wrote: >> >> >> On Oct 11, 2013, at 17:17 , Russell Bryant <rbry...@redhat.com >> <mailto:rbry...@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. > > What I envision here would be another repository/project under the > OpenStack Compute program. You can sort of look at it as similar to > python-novaclient, even though that project uses the same review team > right now. > > So, that means it would also be a separate release deliverable. It > wouldn't be integrated into the main nova release. They could be > released at the same time, though. > > We could either have a single repo: > > openstack/nova-extra-drivers > > or a repo per driver that wants to split: > > openstack/nova-driver-hyperv > +1 for openstack/nova-driver-hyperv That would be perfect. Fast bug fixes, independent reviewers and autonomous blueprints management. Our users would cry of joy for such a solution. :-) > The latter is a bit more to keep track of, but might make the most sense > so that we can have a review team per driver. > >> Stability of the driver's interface has never been a particular issue to >> prevent this to happen IMO. > > Note that I would actually *not* want to necessarily guarantee a stable > API here for master. We should be able to mitigate sync issues with CI. > >> We should think about how to handle the testing, considering that we are >> getting ready with the CI gate. > > Hopefully the testing isn't too much different. It's just grabbing the > bits from another repo. > > Also note that I have a session for the summit that is intended to talk > about all of this, as well: > > http://summit.openstack.org/cfp/details/4 Sure, looking forward to meet you there! > > -- > Russell Bryant > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
