On 29 November 2016 at 10:08, Doug Hellmann <d...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
