Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches

[Shuah Khan <skhan@linuxfoundation.org>]

On 4/22/21 4:35 AM, Mauro Carvalho Chehab wrote:
> Hi James,
> 
> Em Wed, 21 Apr 2021 11:35:36 -0700
> James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:
> 
>> I've long been on record as not really being a fan of trivial patches
>> because they can cause merge issues with current patches and introduce
>> bugs, particularly in older drivers, that don't get detected for a long
>> while.  However, the recent events with the University of Minnesota:
>>
>> https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/
>>
>> Have elevated the risk factor around trivial patches claiming to fix
>> bugs to the point where it looks like there's no such thing as a truly
>> trivial patch and they all need reviewing.
>>
>> Our policy in SCSI for a long time has been no trivial patches accepted
>> to maintained drivers, and I think that would be a good start if
>> adopted kernel wide, but I think the next policy should be no trivial
>> bug fix without a pointer to the actual bug report or report from a
>> trusted static checker.  This would likely mean we have to create a
>> list of trusted static checkers ... obviously 0day and coverity but
>> what else?
> 
> I agree that we should have a "Rethinking the acceptance policy" talk
> at the Maintainer Summit, but it should cover a scope wider than just
> trivial patches. At least the patches I checked, sent from "@unm.edu"
> to media subsystem, they all looked good enough to be merged[1].
> 
> The main question is actually what's the degree of confidence a
> maintainer can rely on a patch sent from a random contributor.
> 
> That's not an easy task.
> 
> I mean, usually, each maintainer develops internally a "trust score"
> from subsystem's contributors, but such trustee level is usually not
> shared with other maintainers.
> 
> When a developer reaches a certain level, maintainers are willing
> to merge their work faster as they know that the developer is
> there for a while and it is not trying to harm the community.
> 
> Perhaps one thing that we could add would be a
> scripts/get_developer_trustee_status, which would be returning
> a set of indicators that would help the maintainer to know
> how much it can trust a random contributor, like:
> 
> 	- how many drivers and patches a contributor has written;
> 	- how long and how frequent he's sending Kernel patches;
> 	- what subsystems received patches from him;
> 	- if the developer isn't on a blacklist/graylist.
> 
> 

This will put new developers at disadvantage. Let's think this through
before adding barriers for entry.

thanks,
-- Shuah