Open Stack

On Tue, Aug 9, 2016 at 4:53 PM, Sean McGinnis <sean.mcginnis at gmx.com> wrote:

> .
> >
> > Mike, you must have left the midcycle by the time this topic came
> > up. On the issue of out-of-tree drivers, I specifically offered this
> > proposal (a community managed mechanism for distributing driver
> > bugfix backports) as an compromise alternative to try to address the
> > needs of both camps. Everyone who was in the room at the time (plus
> > DuncanT who wasn't) agreed that if we had that (a way to deal with
> > backports) that they wouldn't want drivers out of the tree anymore.
> >
> > Your point of view wasn't represented so go ahead and explain why,
> > if we did have a reasonable way for bugfixes to get backported to
> > the releases customers actually run (leaving that mechanism
> > unspecified for the time being), that you would still want the
> > drivers out of the tree.
> >
> > -Ben Swartzlander
>
> The conversation about this started around the 30 minute point here if
> anyone is interested in more of the background discussion on this:
>
> https://www.youtube.com/watch?v=g3MEDFp08t4
>
> __________________________________________________________________________
> 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
>

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

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.

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.

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.

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.

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.

Thanks,
John ​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160809/adaeb81c/attachment.html>