<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 9, 2016 at 4:53 PM, Sean McGinnis <span dir="ltr"><<a href="mailto:sean.mcginnis@gmx.com" target="_blank">sean.mcginnis@gmx.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">.<br>
><br>
> Mike, you must have left the midcycle by the time this topic came<br>
> up. On the issue of out-of-tree drivers, I specifically offered this<br>
> proposal (a community managed mechanism for distributing driver<br>
> bugfix backports) as an compromise alternative to try to address the<br>
> needs of both camps. Everyone who was in the room at the time (plus<br>
> DuncanT who wasn't) agreed that if we had that (a way to deal with<br>
> backports) that they wouldn't want drivers out of the tree anymore.<br>
><br>
> Your point of view wasn't represented so go ahead and explain why,<br>
> if we did have a reasonable way for bugfixes to get backported to<br>
> the releases customers actually run (leaving that mechanism<br>
> unspecified for the time being), that you would still want the<br>
> drivers out of the tree.<br>
><br>
> -Ben Swartzlander<br>
<br>
</span>The conversation about this started around the 30 minute point here if<br>
anyone is interested in more of the background discussion on this:<br>
<br>
<a href="https://www.youtube.com/watch?v=g3MEDFp08t4" rel="noreferrer" target="_blank">https://www.youtube.com/watch?<wbr>v=g3MEDFp08t4</a><br>
<div class="HOEnZb"><div class="h5"><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 class="gmail_extra"><div class="gmail_default" style="font-family:monospace,monospace">​I don't think anybody is whining at all here, we had a fairly productive discussion at the mid-cycle surrounding this topic and I do think there are some valid advantages to this approach regardless of the QA question.  Note that it's been pointed out we weren't talking about or considering advertising this *special* branch as tested by the standard means or gate CI etc.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">We did discuss this though mostly in the context of helping the package maintainers and distributions.  The fact is that many of us currently offer backports of fixes in our own various github accounts.  That's fine and it works well for many.  The problem we were trying to address however is that this practice is rather problematic for the distros.  For example RHEL, Helion or Mirantis are most certainly not going to run around cherry picking change sets from random github repos scattered around.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">The context of the discussion was that by having a long lived *driver* (emphasis on driver) branch there would be a single location and an *easy* method of contact and communication regarding fixes to drivers that may be available for stable branches that are no longer supported.  This puts the burden of QA/Testing mostly on the vendors and distros, which I think is fine.  They can either choose to work with the Vendor and verify the versions for backport on a regular basis, or they can choose to ignore them and NOT provide them to their customers.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">I don't think this is an awful idea, and it's very far from the "drivers out of tree" discussion.  The feedback from the distro maintainers during the week was that they would gladly welcome a model where they could pull updates from a single driver branch on a regular basis or as needed for customers that are on *unsupported* releases and for whom a fix exists.  Note that support cycles are not the same for the distros as they are of the upstream community.  This is in no way proposing a change to the existing support time frames or processes we have now, and in that way it differs significantly from proposals and discussions we've had in the past.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">The basic idea here was to eliminate the proliferation of custom backport patches scattered all over the web, and to ease the burden for distros and vendors in supporting their customers.  I think there may be some concepts to iron out and I certainly understand some of the comments regarding being disingenuous regarding what we're advertising.  I think that's a misunderstanding of the intent however, the proposal is not to extend the support life of stable from an upstream or community perspective but instead the proposal is geared at consolidation and tracking of drivers.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">If this isn't something we can come to an agreement on as a community, then I'd suggest we just create our own repo on github outside of upstream and have it serve the same purpose.  </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Thanks,</div><div class="gmail_default" style="font-family:monospace,monospace">John ​</div><br></div></div>