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
