Re: libmlx4 and libmlx5 git trees? Who is handling those?

[Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2712 bytes --]

On 09/28/2015 06:08 PM, Woodruff, Robert J wrote:
> Jason wrote,
>> IMHO - we should be talking about getting to the point where we can
>> deliver the kernel rc and uapi rc together to someplace like UNH
>> and vendor internal labs and >expect them to test that pair.
>> Regularly, ideally on the kernel release time line.
> 
> I am all for doing more testing earlier, but I am not sure that
> people (like UNH and the vendor validation teams will sign up to do
> it. This would essentially double their testing effort (and costs),
> first testing the user-space packages with the upstream kernel that
> is under development, but also still having to test what comes out of
> the distro or OFED. This is because it is what is in OFED and/or the
> distro that their customers will actually run. Very few customers
> actually run the kernel.org kernel, they run what is in the distro. 
> And BTW, UNH gets paid to do testing, so someone would have to cough
> up the $$ to get them to add this additional testing.

I disagree Bob.

> So it all really comes down to resources and cost and being able to
> justify that doing more testing of upstream code is worth it.

Hopefully this isn't too blunt, but the EWG has the open source paradigm
ass-backwards.

Right now, OS distros (us and SuSE) do their own releases with their own
QE testing.

Upstream we have some people from different companies participating and
contributing code, but with admittedly thin testing resources devoted to
upcoming upstream kernels.  We catch some things, but I've also see
something slip through the cracks on mlx4 hardware in both of the last
two upstream kernel releases.

The EWG does its own integration and testing work for OFED.

Finally, the UNH-IOL does an entirely different type of testing, but no
fixes.

If an end users wants to know if bug X is fixed, then it matters who
found the bug because it is likely fixed in that group's product, but
not necessarily in the other group's products.  If a user needs both bug
X and bug Y fixed, and they were fixed by different groups, then things
are screwed.

That's not how open source is supposed to work.  That is not the best
use of all of our time.  First and foremost, we should all be
concentrating on upstream, because that is the work that pays off for
all of the people distributing this code.  You say end users don't use
upstream?  Of course they do.  No matter whether they use OFED or Red
Hat or SuSE or something else, all of them start with upstream.  Put the
effort where you get the most payback.

-- 
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]