Re: [MAINTAINERS SUMMIT] Maintainer burnout

[Jan Kara <jack@suse.cz>]

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 - you don't want buggy or misdesigned stuff to get
into the subsystem you work with because that's going to make life harder
for everybody including you in the future. And I understand the "tragedy of
commons" (IOW selfishness) works against this so incentives or
review-trading or other methods can help but ultimately it is IMHO about
making people understand and accept this shared responsibility...

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