Re: [MAINTAINERS SUMMIT] Maintainer burnout

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Wed, Aug 16, 2023 at 01:14:46PM -0700, Luis Chamberlain wrote:
> On Wed, Aug 16, 2023 at 02:08:08PM -0400, Josef Bacik wrote:
> > Maintainers/long time developers are burning out.  At the same time there's
> > frustration from new comers who have trouble getting their patches accepted.  We
> > have instances of arguments between longtime developers which leads to more
> > frustration because it drags on the development process.
> 
> <-- snip -->
> 
> > Automate everything: I hate email, that is no secret, but even with email we can
> > automate a lot of things.  The btrfs team built out the GH CI so developers can
> > drive their own testing, spreading the load.  Eventually I hope to get to the
> > point where the merging of patches is automated away so we don't have to deal
> > with those mechanics.
> > 
> > Developing strategies to handle the more mundane tasks of managing our projects
> > will help free us to engage better with our communities, and guide people to be
> > better developers, feeding back into the ecosystem that will help reduce the
> > pain.  Thanks,
> 
> I have been thinking about *many* of these things *for years*, but also *doing*.
> 
> In the *doing* part at the last LSFMM this year I described challenges I have
> faced in this *doing*, but I think it is useful to itemize a few of them
> so they are reminders:
> 
>   a) hardware resources
>   b) push button people / reporting / etc
> 
> Today a) is resolved typically by either companies interested and
> keeping things private (legal or whatnot) or sharing hardware resources
> with community members (Samsung has let me share a big baremetal server
> for community testing), and lately we also now have Oracle offering OCI
> instances. I have *yet* to hear back from any other cloud provider.
> 
> The economic downturn makes a) harder today, whereas a few years before
> I was hinted this was *not* a problem. And so we must take anything we
> can get for it.
> 
> Jeff Layton has also hinted that developers tend prefer for resources to
> be independent of just one company, ie, we can't just have one sole
> provider. I believe this is the right approach. Loosing my test rig
> after I switched an employer once made upkeeping XFS stable backporting
> work just not possible long ago and, fortunately, today we have a team of
> good folks with hw resources from 3 different companies to succeed. This
> wasn't planned. It just happened.
> 
> So to help with automation to help with the burnout, there is a "meta"
> aspect of a) then: proactive planning to get enough public resources for
> community developers to step up to help, whether that be to backport /
> test stable fixes, or resources for future automation of tests.
> 
> If your subsystem is not ready to discuss a) yet, that likely might be
> because different companies / folks use different things to test subsystems /
> regressions / new patches. And there in lies another "meta" issue.
> 
> In the *worst* case there are simply no tests, *or* maintainers suggesting
> there is no way to automate *cough*.
> 
> There are also those that believe testing is super awesome, but seem to
> shy away from the idea that our community is not ready for *requiring*
> tests for kernel development / new patches / features / etc. IMHO evidence
> of burnouts is a strong suggestion we should *strive* for it. The issue
> is that typically this last part is an afterthought in the worst case,
> and even with best intentions, can sometimes be a resource constrain
> whether that be physical hardware or the b) part mentioned above.
> 
> What does this tell us, if we care about this? *If* automation is to be
> a serious consideration it *must* be just as good as the kernel code we
> write. And so I think it would help for those that *do* care about this
> to start thinking about all these things proactively in this sense.
> 
> As for b) feedback from LSFMM was let's just automate it too. While
> sensible, without resource consideration its a slow steep slope. But
> I think we're getting better at that with time. Not only do we need
> to think about writing test coverage but also the other parts of b).
> 
> In so far as making it possible to get b) to help, my current excitement
> surrounds around what Song Liu mentioned to me at LSFMM and then
> quickly demonstrated that the eBPF folks are doing with patchwork.
> Get the patches to be tested automatically, and *immediately*
> patch reviewers and maintainers can get feedback if something is not even
> worth reviewing.

This is interesting, do you have any link to share to related resources
?

> There are some other R&D type of ideas out there I have shared with some
> peers and some have shared with me too, which could probably help long
> term too, but one step at a time.
> 
> To help with b) my goal was to leverage and learn what eBPF folks have
> done, allow kdevops to use it, and then start integrating with patchwork
> for either the stuff I maintain or for the subsystems that are
> interested in leverating the automation framework behind kdevops.
> 
> A boring but perhaps fitting way to think about what we do is to start
> thinking about what we do with kernel development as a public utlity and
> service and we just need to automate testing of this public utility.
> 
> I'd be very interested in talking about this if invited but my current
> flight departs in the afternoon, but I could perhaps see to fly the next day if
> this topic is chosen / I get an invite.

-- 
Regards,

Laurent Pinchart