Re: [net-next PATCH 00/15] eth: fbnic: Add network driver for Meta Platforms Host Network Interface

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Apr 09, 2024 at 07:43:07AM -0700, Alexander Duyck wrote:

> I see. So this is what you were referencing. Arguably I can see both
> sides of the issue. Ideally what should have been presented would have
> been the root cause of why the diff

Uh, that almost never happens in the kernel world. Someone does a
great favour to us all to test rc kernels and finds bugs. The
expectation is generally things like:

 - The bug is fixed immediately because the issue is obvious to the
   author
 - Iteration and rapid progress is seen toward enlightening the author
 - The patch is reverted, often rapidly, try again later with a good
   patch

Unsophisticated reporters should not experience regressions,
period. Unsophisticated reporters shuld not be expected to debug
things on their own (though it sure is nice if they can!). We really
like it and appreciate it if reporters can run experiments!

In this particular instance there was some resistance getting to a fix
quickly. I think a revert for something like this that could not be
immediately fixed is the correct thing, especially when it effects
significant work within the community. It gives the submitter time to
find out how to solve the regression.

That there is now so much ongoing bad blood over such an ordinary
matter is what is really distressing here.

I think Leon's point is broadly that those on the "vendor" side seem
to often be accused of being a "bad vendor". I couldn't help but
notice the language from Meta on this thread seemed to place Meta
outside of being a vendor, despite having always very much been doing
typical vendor activities like downstream forks, proprietary userspace
and now drivers for their own devices.

In my view the vendor/!vendor distinction is really toxic and should
stop.

Jason