Open Stack

On 10/11/2013 01:18 PM, Alessandro Pilotti wrote:
> 
> 
> On Oct 11, 2013, at 19:04 , John Griffith <john.griffith at solidfire.com
> <mailto:john.griffith at solidfire.com>>
>  wrote:
> 
>>
>>
>>
>> On Fri, Oct 11, 2013 at 9:12 AM, Bob Ball <bob.ball at citrix.com
>> <mailto:bob.ball at citrix.com>> wrote:
>>
>>     > -----Original Message-----
>>     > From: Russell Bryant [mailto:rbryant at redhat.com
>>     <mailto:rbryant at redhat.com>]
>>     > Sent: 11 October 2013 15:18
>>     > To: openstack-dev at lists.openstack.org
>>     <mailto:openstack-dev at lists.openstack.org>
>>     > Subject: Re: [openstack-dev] [Hyper-V] Havana status
>>     >
>>     > > As a practical example for Nova: in our case that would simply
>>     include the
>>     > following subtrees: "nova/virt/hyperv" and "nova/tests/virt/hyperv".
>>     >
>>     > 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?
>>
>>     I think that all drivers that are officially supported must be
>>     treated in the same way.
>>
>>     If we are going to split out drivers into a separate but still
>>     official repository then we should do so for all drivers.  This
>>     would allow Nova core developers to focus on the architectural
>>     side rather than how each individual driver implements the API
>>     that is presented.
>>
>>     Of course, with the current system it is much easier for a Nova
>>     core to identify and request a refactor or generalisation of code
>>     written in one or multiple drivers so they work for all of the
>>     drivers - we've had a few of those with XenAPI where code we have
>>     written has been pushed up into Nova core rather than the XenAPI tree.
>>
>>     Perhaps one approach would be to re-use the incubation approach we
>>     have; if drivers want to have the fast-development cycles
>>     uncoupled from core reviewers then they can be moved into an
>>     incubation project.  When there is a suitable level of integration
>>     (and automated testing to maintain it of course) then they can
>>     graduate.  I imagine at that point there will be more development
>>     of new features which affect Nova in general (to expose each
>>     hypervisor's strengths), so there would be fewer cases of them
>>     being restricted just to the virt/* tree.
>>
>>     Bob
>>
>>     _______________________________________________
>>     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
>>
>>
>> I've thought about this in the past, but always come back to a couple
>> of things.
>>
>> Being a community driven project, if a vendor doesn't want to
>> participate in the project then why even pretend (ie having their own
>> project/repo, reviewers etc).  Just post your code up in your own
>> github and let people that want to use it pull it down.  If it's a
>> vendor project, then that's fine; have it be a vendor project.
>>
> 
> There are quite a few reasons why putting this project soemwehere else
> wouldn't make sense:
> 
> 1) It's not a vendor project, we're having contributions from community
> members belonging to other companies as well
> 2) Legitimation. Users want to know that this code is going to be there
> with or without us
> 3) Driver interface stability, as everybody is against a stable
> interface (even if de facto is perfectly stable)
> 4) it's not a vendor project, did I say it already? :-)
> 
> Said that, we are constantly on the verge of starting pushing code to
> customers from a fork, but we are trying as hard as possible to avoid as
> it is definitely bad for the whole community. 

A vendor project doesn't mean you couldn't accept contributions.  It
means that it would be primarily developed/maintained/managed by someone
other than the OpenStack project, which would in this case be Microsoft
(or its contractor(s)).

I totally agree with the benefits of staying in tree.  The question is
whether you are willing to pay the cost to get those benefits.

Splitting into repos and giving over control is starting to feel like
giving you all of the benefits (primarily being "legitimate" as you
say), without having to pay the cost (more involvement).

The reason we're at this point and having this conversation about the
fate of hyper-v is that there has been an imbalance.

-- 
Russell Bryant