Open Stack

On 12.10.2013, at 20:22, "Dan Smith" <dms at danplanet.com> wrote:

>> From the user perspective, splitting off the projects seems to be 
>> focussing on the ease of commit compared to the final user 
>> experience.
> 
> I think what you describe is specifically the desire that originally
> spawned the thread: making the merging of changes to the hyper-v driver
> faster by having them not reviewed by the rest of the Nova team. It
> seems to be what the hyper-v developers want, not necessarily what the
> Nova team as a whole wants.
> 
>> An 'extras' project without *strong* testing co-ordination with
>> packagers such as SUSE and RedHat would end up with the consumers of
>> the product facing the integration problems rather than resolving
>> where they should be, within the OpenStack project itself.
> 
> I don't think splitting out to -extras means that it loses strong
> testing coordination (note that strong testing coordination does not
> exist with the hyper-v driver at this point in time). Every patch to the
> -extras tree could still be unit (and soon, integration) tested against
> the current nova tree, using the proposed patch applied to the -extras
> tree. It just means that a change against nova wouldn't trigger the
> same, which is why the potential for "catch up" behavior would be required.
> 
>> I am sympathetic to the 'extra' drivers problem such as Hyper-V and 
>> powervm, but I do not feel the right solution is to split.
>> 
>> Assuming there is a summit session on how to address this, I can 
>> arrange a user representation in that session.
> 
> Cool, I really think we're at the point where we know the advantages and
> disadvantages of the various options and further face-to-face discussion
> at the summit is what is going to move us to the next stage.
> 

I agree. Looks like we are converging towards a common ground. I'm summing it up here, including a few additional details, for the benefit of who will not join us in HK (sorry, we'll party for you as well :-)):

1) All the drivers will still be part of Nova.

2) One official project (nova-drivers-incubator?) or more than one will be created for the purpose of supporting a leaner and faster development pace of the drivers.

3) Current driver sub-project teams will informally elect their maintainer(s) which will have +2a rights on the new project or specific subtrees.

4) Periodically, code from the new project(s) must be merged into Nova. 
Only Nova core reviewers will have obviously +2a rights here.
I propose to do it on scheduled days before every milestone, differentiated per driver to distribute the review effort (what about also having Nova core reviewers assigned to each driver? Dan was suggesting something similar some time ago).

5) All drivers will be treated equally and new features and bug fixes for master (except security ones) should land in the new project before moving to Nova.

6) CI gates for all drivers, once available, will be added to the new project as well. Only drivers code with a CI gate will be merged in Nova (starting with the Icehouse release as we already discussed).

7) Active communication should be maintained between the Nova core team and the drivers maintainers. This means something more than: "I wrote it on the ML didn't you see it?" :-)

A couple if questions: will we keep version branches on the new project or just master?

Bug fixes for older releases will be proposed to the incubator for the current release in development and to Nova for past versions branches?

Please correct me if I missed something!

Thanks,

Alessandro

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