Hi Jan,

> There are two things here: If I review a patch and I'm not confident I did
> a good job for some parts (because I didn't have time or I just don't know
> that part of the kernel), then I should write that to the reply with
> Reviewed-by tag. That's IMHO a good rule but I don't think you can enforce
> it in any way. You can just ask people that do reviews for your subsystem
> if you think they're omitting this.

I agree to this. This is why I intentionally wrote my theses with words
like "should" and "encourage" because I don't believe in "enforcing"
such a thing.

Nonetheless, having a clear statement worked well for commit messages, I
think. We have spread the word how important good commit messages are
and from what I observe they have become better. I wish for a similar
process with reviews. And from my side, it could be as simple as
"checked everything, all good".

> The second thing is that if human doesn't know something, then he/she has
> a tendency to underestimate how much he/she doesn't know (this even has a
> psychological term "cognitive bias"). So the self-evaluation of "how good is
> my review" is always going to be subjective and it is upto maintainer to
> judge what is the value of the review.

I still consider the mere description of what was reviewed in detail and
what not already helpful. I agree that the maintainer still has to
evaluate the review.

> To give an exaple, Ted Tso (ext4 maintainer) tends to just ignore "empty
> Reviewed-by" replies from people that haven't built enough credit in the
> kernel community by actually finding bugs with their reviews...

This is good to know. I will apply some rules for I2C. Yet, it feels
easier if I2C is not some obscure island but part of something.

Thanks,

   Wolfram