Re: [MAINTAINERS SUMMIT] Maintainer burnout

[Jan Kara <jack@suse.cz>]

On Tue 22-08-23 14:05:23, Leon Romanovsky wrote:
> On Tue, Aug 22, 2023 at 11:46:13AM +0200, Jan Kara wrote:
> > On Mon 21-08-23 21:23:18, Vegard Nossum wrote:
> > > On 8/19/23 08:45, Leon Romanovsky wrote:
> > > > It is worth to try to get honest feedback from active developers/contributors/vendors
> > > > what is their "real" excuse for not doing code review.
> > > > 
> > > > I saw in this thread about "have no time to do code review" answers and we
> > > > all can relate to it, but IMHO it is just an excuse and not the real reason.
> > > > Especially for a people who are employed by big corporations to do their
> > > > upstream work.
> > > 
> > > For some drive-by or would-be reviewers, at least, I think part of the
> > > problem is perverse or misaligned incentives.
> > > 
> > > If you write code and your patches are accepted in the kernel, it counts
> > > towards your commit count, which is a metric that people look at, for
> > > better or worse (probably worse).
> > > 
> > > When you review a patch and you find some problem with it, the patch
> > > will NOT get accepted in the kernel (at least not in that form), and
> > > your name will NOT appear in the git log. So in a way, in order for
> > > your contribution to get recorded, you have to give the patch a
> > > passing grade -OR- you are now on the hook to keep reviewing every
> > > following iteration of the patch until it's in a state where you're
> > > completely sure it doesn't have any problems.
> > > 
> > > (Of course, if you just rubber-stamp your Reviewed-by: on everything
> > > then you are bound to be found out sooner or later -- or at the very
> > > least seen as an unreliable reviewer.)
> > > 
> > > But let's assume you don't give out your Reviewed-by: without having
> > > REALLY checked the patch thoroughly. Even then, mistakes can slip in.
> > > In a way, being a reviewer and missing something critical is even
> > > worse than being the author and missing something critical. Is it even
> > > worth putting your Reviewed-by: on something if you're not 100% sure
> > > this patch is not going to cause an issue? Are people going to trust
> > > you in the future if you make a mistake in your review?
> > > 
> > > Let's say you're completely sure you found an issue with the patch. Why
> > > not just stay silent, hope that nobody catches it, and then submit your
> > > own patch later to fix it? That will get your name in the log. Even
> > > worse, if it's a security issue you can maybe write an exploit for it
> > > and either get a bounty from Google or sell it for serious $$$ to
> > > various malicious actors. [Note that I'm not saying most people would do
> > > this; I don't know. I am just using it as an example to show that the
> > > incentives are disproportionate.]
> > > 
> > > The incentives that remain (as far as I can tell) are:
> > > 
> > > 1) you get familiar with a specific part of the kernel, and
> > > 2) you get goodwill and recognition from other kernel developers.
> > 
> > I agree it is good to create positive incentives to provide good review.
> > But I believe what really makes people do good reviews is the sense of
> > common responsibility.
> 
> Agree as long as "people" word includes whole community together with
> maintainers to share common responsibility.
> 
> Some maintainers feel too much ownership other their subsystems and it
> causes to the lack of trust from everybody involved in the process and
> common responsibility can't be built in that subsystems at all.

I agree. People can hardly have common responsibility when they have the
feeling their opinion doesn't really matter for the maintainer.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR