Re: [MAINTAINERS SUMMIT] Maintainer burnout

Laurent Pinchart
2023-08-21T16:13:11Z

On Fri, Aug 18, 2023 at 07:36:44PM +0100, Mark Brown wrote:
> 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.

As I wrote in a separate e-mail in this thread, my main focus with a
subsystem core developer/maintainer hat is usage of in-kernel and
userspace APIs. This is related to subsystem ongoing maintenance, as
badly used in-kernel APIs will hinder future refactoring, and badly used
userspace APIs will need to be kept forever as we can't break userspace
that depends on them. This knowledge is easier (by not easy) to build
across a larger number of developers, compared to device-specific
knowledge.

With my other hat of driver maintainer, I'm certainly more conservative
reviewing patches for drivers that are used by a very large number of
people, for fear of introducing breakages. Automated tests can help to
some extent, but I don't have a good answer to this problem.

> 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.

--
Regards,

Laurent Pinchart