On Fri, Aug 18, 2023 at 11:40:32AM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Aug 18, 2023 at 06:26:29PM +0300, Laurent Pinchart wrote:

> > Maybe part of the solution here, to share the maintenance burden, is to
> > expect contributors, especially the ones with large financial resources,
> > to spent a certain percentage of their time reviewing code that is in
> > their area of expertise but not in their area of business interest.

> May I add an point that I had struggled in the past with (and it could
> be very well this is not an issue in your subsystem in which case please
> ignore it):

> This idea assumes you trust them to have the same level of expertise
> that you have.

> That is say they do a review but miss the more esoteric semantics (say
> hardware quirks that are documented but only for folks that *grok* the
> hardware). You may know it, but they don't. You accept their patches and
> months later it all blows up. You are unhappy, Linus is screaming about
> it. Burn-out ++.

For those of us working more with drivers for embedded systems this can
be a bit different in that for a lot of drivers realistically nobody is
going to have access to the hardware outside of a fully integrated
product, including you.  I remember talking with someone submitting
drivers for devices like that and them being surprised that I was much
more focused on if the driver was a pain for subsystem integration and
ongoing maintainance than if this undocumented thing I had no access to
worked.

Of course it's not like you can completely ignore things and some
drivers get more exposure to general users than others, but it does help
quite a bit to feed into the risk profile of patches.

> Perhaps the question should be: How to grow the community so that members
> collectively have the same knowledge as you?

And also identify the areas where that's already happening and actually
take advantage of that fact.