Open Stack

On 29 November 2016 at 10:08, Doug Hellmann <doug at doughellmann.com> wrote:

> Excerpts from Zane Bitter's message of 2016-11-29 12:36:03 -0500:
> > 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:
> >
> > a) Neutron to start agreeing with you; or
> > b) The TC to tell Neutron to agree with you; or
>
> I hope I'm not the only one who thinks drivers are important?
>
> I would prefer not to impose obligations on anyone. I wrote up that
> option to explore what it would look like, not because I think it's
> the best outcome.  At the same time, the current approach is actively
> harmful to the overall health of the community by pushing away
> contributors and useful contributions, especially considering the
> different responses to vendor-related issues in other teams.  And
> this does fall within the scope of issues and policies the TC is
> meant to manage.
>
> > c) To do an end run around Neutron by adding it as a separate project
>
> I wouldn't categorize that last one as an end-run. We wouldn't be
> adding the driver team to Neutron, we would be adding it to OpenStack.
> The Neutron team would have no more responsibility for the output of
> a driver team than they do anyone else.
>
> > 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.
>
> I did, in the original post, try to explain why I think it's necessary.
>
>   The OpenStack community wants to encourage collaboration by
>   emphasizing contributions to projects that abstract differences
>   between vendor-specific products, while still empowering vendors
>   to integrate their products with OpenStack through drivers that
>   can be consumed by the abstraction layers
>
> In addition to wanting collaboration between experts in a given
> field, projects support drivers to give deployers choices. Encouraging
> vendors to write drivers furthers both goals. It also encourages
> those same vendors to be active in the community in other ways,
> such as sponsoring events and the Foundation. Whether we achieve
> *that* goal depends on a lot of factors, and we're more successful
> with some vendors than others. Turning away contributions does not
> encourage their participation in any way I can understand.
>
> > 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.
>
> I'll let someone from the Neutron team fill in the details behind their
> decision, because I don't want to misrepresent them.
>

I replied to Zane's initial email. I hope that provides some insight as to
why we went down the path we did.

Thanks,
Armando


>
> Doug
>
> >
> > 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/7e205bba/attachment.html>