Open Stack

On 29 November 2016 at 09:36, Zane Bitter <zbitter at redhat.com> wrote:

> On 29/11/16 10:28, Doug Hellmann wrote:
>
>> Excerpts from Chris Friesen's message of 2016-11-29 09:09:17 -0600:
>>
>>> On 11/29/2016 08:03 AM, Doug Hellmann wrote:
>>>
>>>> I'll rank my preferred solutions, because I don't actually like any of
>>>> them.
>>>>
>>>
>>> Just curious...what would you "actually like"?
>>>
>>> Chris
>>>
>>>
>> My preference is to have teams just handle the drivers voluntarily,
>> without needing to make it a rule or provide a way to have teams
>> that only work on a driver. That's not one of the options we proposed,
>> but the results are like what we would get with option 6 (minus the
>> precedent of the TC telling teams what code they must manage).
>>
>
> I don't have a lot of background on why the driver was removed from the
> Neutron stadium, but reading between the lines it sounds like you think
> that Neutron made the Wrong Call, and that you would like, in order of
> preference:
>

In a nutshell: scalability. The list became huge, the core team was made in
charge of dealing with releases requests, backport requests, infra,
governance and doc changes etc. Any of those changes required a neutron
liasion vouching for them. This became untenable, distracting and defeating
the whole point of breaking down the monolithic codebase we were trying to
move away from. I (the PTL since Mitaka) personally felt that we needed to
empower the individual efforts to be in charge or their own destiny and at
the same time making sure that the neutron project as described by the
governance repo was cohesive and made sense to the eye of someone looking
at the project list.

If the eviction or exclusion of a driver caused a project and its
contributors lose their ATC status, access to horizontal teams services
(e.g. representation on docs.o.o, release.o.o), etc, I always thought that
was wrong; that should have not happened, and I hope this effort led by
Doug can fix that.

The neutron team cares about drivers, and I personally believe that are
very important to the success of the OpenStack community. That's why we
enabled the innovation by breaking them out and keeping/augmenting the
extension points provided by the core platform so that they are not stifled
by the chokepoint that the core team may represent. At the same time, I
care about quality and consistency, and I want to be proudly standing
behind the stuff I am involved in, and as such I don't want to be
erroneously associated with initiatives I (and the core team) cannot ever
have the bandwidth to deal with.


> a) Neutron to start agreeing with you; or
> b) The TC to tell Neutron to agree with you; or
> c) To do an end run around Neutron by adding it as a separate project
>
> Individual projects (like Neutron) have pretty wide latitude to add
> repositories if they want, and are presumably closer to the issues than
> anyone. So it seems strange that we're starting with a discussion about how
> to override their judgement, rather than one about why we think that's
> necessary.
>
> What are the obstacles to the Neutron team agreeing to host these drivers?
> Perhaps the TC is in a position to remove some of those obstacles? That
> seems preferable to imposing new obligations on projects.
>
> cheers,
> Zane.
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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/20161202/20f99d72/attachment.html>