<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 29 November 2016 at 10:08, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Zane Bitter's message of 2016-11-29 12:36:03 -0500:<br>
<span class="">> On 29/11/16 10:28, Doug Hellmann wrote:<br>
> > Excerpts from Chris Friesen's message of 2016-11-29 09:09:17 -0600:<br>
> >> On 11/29/2016 08:03 AM, Doug Hellmann wrote:<br>
> >>> I'll rank my preferred solutions, because I don't actually like any of<br>
> >>> them.<br>
> >><br>
> >> Just curious...what would you "actually like"?<br>
> >><br>
> >> Chris<br>
> >><br>
> ><br>
> > My preference is to have teams just handle the drivers voluntarily,<br>
> > without needing to make it a rule or provide a way to have teams<br>
> > that only work on a driver. That's not one of the options we proposed,<br>
> > but the results are like what we would get with option 6 (minus the<br>
> > precedent of the TC telling teams what code they must manage).<br>
><br>
> I don't have a lot of background on why the driver was removed from the<br>
> Neutron stadium, but reading between the lines it sounds like you think<br>
> that Neutron made the Wrong Call, and that you would like, in order of<br>
> preference:<br>
><br>
> a) Neutron to start agreeing with you; or<br>
> b) The TC to tell Neutron to agree with you; or<br>
<br>
</span>I hope I'm not the only one who thinks drivers are important?<br>
<br>
I would prefer not to impose obligations on anyone. I wrote up that<br>
option to explore what it would look like, not because I think it's<br>
the best outcome.  At the same time, the current approach is actively<br>
harmful to the overall health of the community by pushing away<br>
contributors and useful contributions, especially considering the<br>
different responses to vendor-related issues in other teams.  And<br>
this does fall within the scope of issues and policies the TC is<br>
meant to manage.<br>
<span class=""><br>
> c) To do an end run around Neutron by adding it as a separate project<br>
<br>
</span>I wouldn't categorize that last one as an end-run. We wouldn't be<br>
adding the driver team to Neutron, we would be adding it to OpenStack.<br>
The Neutron team would have no more responsibility for the output of<br>
a driver team than they do anyone else.<br>
<span class=""><br>
> Individual projects (like Neutron) have pretty wide latitude to add<br>
> repositories if they want, and are presumably closer to the issues than<br>
> anyone. So it seems strange that we're starting with a discussion about<br>
> how to override their judgement, rather than one about why we think<br>
> that's necessary.<br>
<br>
</span>I did, in the original post, try to explain why I think it's necessary.<br>
<span class=""><br>
  The OpenStack community wants to encourage collaboration by<br>
  emphasizing contributions to projects that abstract differences<br>
  between vendor-specific products, while still empowering vendors<br>
  to integrate their products with OpenStack through drivers that<br>
  can be consumed by the abstraction layers<br>
<br>
</span>In addition to wanting collaboration between experts in a given<br>
field, projects support drivers to give deployers choices. Encouraging<br>
vendors to write drivers furthers both goals. It also encourages<br>
those same vendors to be active in the community in other ways,<br>
such as sponsoring events and the Foundation. Whether we achieve<br>
*that* goal depends on a lot of factors, and we're more successful<br>
with some vendors than others. Turning away contributions does not<br>
encourage their participation in any way I can understand.<br>
<span class=""><br>
> What are the obstacles to the Neutron team agreeing to host these<br>
> drivers? Perhaps the TC is in a position to remove some of those<br>
> obstacles? That seems preferable to imposing new obligations on projects.<br>
<br>
</span>I'll let someone from the Neutron team fill in the details behind their<br>
decision, because I don't want to misrepresent them.<br></blockquote><div><br></div><div>I replied to Zane's initial email. I hope that provides some insight as to why we went down the path we did.</div><div><br></div><div>Thanks,</div><div>Armando</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Doug<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> cheers,<br>
> Zane.<br>
><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>