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. 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
