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

[Mauro Carvalho Chehab <mchehab+huawei@kernel.org>]

Em Thu, 22 Apr 2021 09:24:01 -0400
Konstantin Ryabitsev <konstantin@linuxfoundation.org> escreveu:

> On Thu, Apr 22, 2021 at 12:35:59PM +0200, Mauro Carvalho Chehab wrote:
> > 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.  
> 
> I must point out that "karma" systems are quite ripe for abuse and can create
> negative dynamics within the project. Right now, without an accepted framework
> of cryptographic patch attestation, high-karma accounts will be more likely to
> be targeted for impersonation -- typo spoofing, account hijacking, "From"
> fudging [*], etc.

Good point.

> Even if we do everything right and implement strong cryptographic end-to-end
> attestation,

IMO, it makes sense to improve our workflow towards having gpg-signed patches
that are cross-signed by Kernel maintainers from developers that are regular
contributors.

Of course, a change like that takes time.

> I think karma makes sense within the vertical confines of submaintainer
> hierarchy -- X collects patches and sends a pull request to Y; Y verifies the
> signature on the pull request, gives it a quick review and submits another
> request to Z, etc. Exporting the "karma points" outside of this hierarchy
> doesn't really make sense.

Yeah, it makes a lot sense vertically, but it also makes sense horizontally:
the karma from a long time subsystem maintainer is higher than a random
contributor, even when contributing to a different subsystem. The reason is
that it is unlikely that such contributor would just disappear in the thin
air if something bad comes up from merging his patch.

Thanks,
Mauro