[Ofa_boardplus] OFED releases

[Christoph Lameter]

Note that Jason also says that the sites are also actively working on
getting stuff submitted upstream to minimize their delta as well as working
with the distros to make sure things are straight. We have done that as a
company but I do not see OFED do this. If OFED would work in a
collaborative way with distros and upstream to ensure that the distros
include the necessary changes then that would be a good thing. One of the
key things then will have to adopt the methods and processes to work with
upstream and the distros and to interact with them in a regular fashion,.

On Tue, May 16, 2017 at 12:48 PM, Paul Grun <grun at cray.com> wrote:

> >The only avenue left is a technical solution - someone has to fund the
> work to
> >actually go and create a fork that matches what the sites need, pulling
> from the
> >vendor forks, and do this faster than the upstream process would get it
> done.
>
> Would it be unreasonable to think of the EWG as being the technical body
> that could do what Jason suggests?
>
> >-----Original Message-----
> >From: Ofa_boardplus [mailto:ofa_boardplus-bounces at lists.openfabrics.org]
> On
> >Behalf Of Jason Gunthorpe
> >Sent: Thursday, May 11, 2017 4:05 PM
> >To: Atchley, Scott <atchleyes at ornl.gov>
> >Cc: ofa_boardplus at lists.openfabrics.org
> >Subject: Re: [Ofa_boardplus] OFED releases
> >
> >On Thu, May 11, 2017 at 09:44:11PM +0000, Atchley, Scott wrote:
> >
> >> Again, I am not arguing for a change in anyone’s workflow from pushing
> >> upstream first. But while upstream debates implementation and while
> >> the eventual design works its way to the distro backports, what should
> >> users do with hardware on their floor?
> >
> >They need to use the fork of the software that vendor provides. There is
> no other
> >answer. Only the vendor is going to be willing to support and develop
> that forked
> >code.
> >
> >Your #2 problem is the real intractable issue.
> >
> >The upstream neutral collaborative process is how we have been successful
> in
> >getting the vendors to work together, at all. That has become an industry
> wide
> >defacto agreed upon way to work on a shared code base.
> >
> >There is no way, politically, to just short circuit that process and keep
> the vendors
> >engaged.
> >
> >It isn't reasonable to ask the vendors to union their forks of the RDMA
> stack
> >outside of the upstream process - there are overlaps and disagreements,
> this
> >would create a different layer of arguing. As a group, the vendors have no
> >incentive to do that.
> >
> >The only avenue left is a technical solution - someone has to fund the
> work to
> >actually go and create a fork that matches what the sites need, pulling
> from the
> >vendor forks, and do this faster than the upstream process would get it
> done.
> >
> >Frankly, this is what all the big cloud operators do internally - they
> fund a kernel
> >and infrastructure development team to mangle the software into the shape
> they
> >want, and upstream things to minimize their maintenance cost.
> >
> >Jason
> >_______________________________________________
> >Ofa_boardplus mailing list
> >Ofa_boardplus at lists.openfabrics.org
> >http://lists.openfabrics.org/mailman/listinfo/ofa_boardplus
> _______________________________________________
> Ofa_boardplus mailing list
> Ofa_boardplus at lists.openfabrics.org
> http://lists.openfabrics.org/mailman/listinfo/ofa_boardplus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofa_boardplus/attachments/20170516/a103902b/attachment.html>