[RFC] kernel/ review rules

[RFC] kernel/ review rules

[Bradley Morgan]

(CCed some people I talk to loads, I don't think I should CC every single
kernel/ maintainer, that would be fun otherwise, if you feel others should
be CCed, please CC them)

Hey everyone, it's been about God knows how long since I've started
reviewing kernel/, here are my current stats:
    
Reviewed-by     
13
Tested-by          
7
Reported-by        
1

Pretty good, ngl, I'm happy to review these patches, and I'm happy to
review the slop patches, and the people's patches, and anything with
[PATCH] in the damn title.

My very kind slop tool generated these stats for me.. 

So I've had some controversy about, like, how I do these reviews, some
people say how I review without context, or other stuff, like I'm wrong.

And I would like to suggest a fix to this, stuff.

So, when I do reviews from now on, if I haven't reviewed the patch
super vigourisly, e.g: for nits, or for like little things, instead of
adding my R-B, I'll add this instead:

Acked-by: Bradley Morgan <include@grrlz.net>

Thanks for letting me review kernel/ patches!



Thanks!

Re: [RFC] kernel/ review rules

[Andrew Morton]

On Fri, 21 Aug 2026 01:20:47 +0100 Bradley Morgan <include@grrlz.net> wrote:

> So, when I do reviews from now on, if I haven't reviewed the patch
> super vigourisly, e.g: for nits, or for like little things, instead of
> adding my R-B, I'll add this instead:
> 
> Acked-by: Bradley Morgan <include@grrlz.net>

That's conventional.

Here's my interpretation:

Acked-by:			"cool changelog!"
Reviewed-by: + nothing		"cool changelog and I scrolled through it"
Reviewed-by: + commentary:	"I reviewed it!"

Re: [RFC] kernel/ review rules

[Bradley Morgan]

On 21 August 2026 02:00:45 BST, Andrew Morton <akpm@linux-foundation.org>
wrote:
>On Fri, 21 Aug 2026 01:20:47 +0100 Bradley Morgan <include@grrlz.net>
>wrote:
>
>> So, when I do reviews from now on, if I haven't reviewed the patch
>> super vigourisly, e.g: for nits, or for like little things, instead of
>> adding my R-B, I'll add this instead:
>> 
>> Acked-by: Bradley Morgan <include@grrlz.net>
>
>That's conventional.
>
>Here's my interpretation:
>
>Acked-by:			"cool changelog!"
>Reviewed-by: + nothing		"cool changelog and I scrolled through it"

^

Some maintainers moan when I do this 

So acked by fixes


>Reviewed-by: + commentary:	"I reviewed it!"
>
>



Thanks!

Re: [RFC] kernel/ review rules

[Theodore Tso]

On Fri, Aug 21, 2026 at 08:30:02AM -0500, Bradley Morgan wrote:
> >Acked-by:			"cool changelog!"

As a maintainer, I completely ignore an Acked-by unless it comes from
another Maintainer, in which case it means that the other Maintainer
is OK with that commit which might affect their subsystem (either
directly because it modifies code in their subsystem or indirectly
because it changes functions that their subsystem depends upon).

As a result I will likely drop an Acked-by and not include it in the
git commit descritpion if it comes from a non-Maintainer.

> >Reviewed-by: + nothing		"cool changelog and I scrolled through it"
> >Reviewed-by: + commentary:	"I reviewed it!"

If there is a reviewed-by, and other problems are discovered by other
reviewers, the reputation of the person who submitted the Reviewed-by
will go down, and with enough bogus reviewed-by, I will start ignoring
that reviewer and drop their Reviewed-by from the git commit
description.

And if there is Reviewed-by commentary which is actively wrong, I may
start sending patch submitters form letters informing them that they
should feel free to ignore reviews from Reviewer XXXXX since the
reviews may be unreliable.

So I wouldn't focus on review numbers, but review *quality*.

Cheers,

						- Ted

Re: [RFC] kernel/ review rules

[Bradley Morgan]

On 21 August 2026 13:13:08 BST, Theodore Tso <tytso@mit.edu> wrote:
>On Fri, Aug 21, 2026 at 08:30:02AM -0500, Bradley Morgan wrote:
>> >Acked-by:			"cool changelog!"
>

well, ik I may not be good enough for your time, but here goes, :)

>As a maintainer, I completely ignore an Acked-by unless it comes from
>another Maintainer, in which case it means that the other Maintainer
>is OK with that commit which might affect their subsystem (either
>directly because it modifies code in their subsystem or indirectly
>because it changes functions that their subsystem depends upon).
>
>As a result I will likely drop an Acked-by and not include it in the
>git commit descritpion if it comes from a non-Maintainer.
>

Fair enough.

>> >Reviewed-by: + nothing		"cool changelog and I scrolled through it"
>> >Reviewed-by: + commentary:	"I reviewed it!"
>
>If there is a reviewed-by, and other problems are discovered by other
>reviewers, the reputation of the person who submitted the Reviewed-by
>will go down, and with enough bogus reviewed-by, I will start ignoring
>that reviewer and drop their Reviewed-by from the git commit
>description.
>

well, this one is, ok.

Me personally, doing reviews, do reviews for a reason, not representing any
company or anything, but I personally do this as a mental release, when
stuff gets bad, I review patches, it's a fix.


If a reviewer does a crappy review, maybe once or twice, then don't ignore
the guy yet, people are wrong, it always happens.


If it's a multiple time thing, or consistent, then we have some talking to
do, because I suspect: AI, or just the fact the reviewer doesn't
understand the code sufficiently enough to provide a review, what I would
do in this case is send a off list email saying something along the lines
of:


"What the hell's going on XXXX? You got X reviews wrong, and you nearly
just got (Bad thing, bug or regression) merged! I want you to be honest
with me, because I can help you, are you using AI for review?"

And if they say yes, I'll probably delegate this to a smarter person, not
as in let him do the brunt, as in for advice, if he doesn't understand the
code, ill help him get a understanding of the code in order to make better
reviews.


>And if there is Reviewed-by commentary which is actively wrong, I may
>start sending patch submitters form letters informing them that they
>should feel free to ignore reviews from Reviewer XXXXX since the
>reviews may be unreliable.
>

I kinda ranted above ^


>So I wouldn't focus on review numbers, but review *quality*.
>

Ack.

>Cheers,
>
>						- Ted
>


I just woke up. So bare with my very low grammar rant, please? :)

Thanks!