Open Stack

On 10/11/2013 10:41 AM, Alessandro Pilotti wrote:
> 
> 
> 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.

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

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

-- 
Russell Bryant