Re: [PATCH] MAINTAINERS: add Josh Law as reviewer for library code

[Josh Law <hlcj1234567@gmail.com>]

13 Mar 2026 15:57:04 Jens Axboe <axboe@kernel.dk>:

> On 3/13/26 9:51 AM, Josh Law wrote:
>> 13 Mar 2026 15:48:32 Lorenzo Stoakes (Oracle) <ljs@kernel.org>:
>>
>>> +cc David for mention
>>>
>>> On Fri, Mar 13, 2026 at 04:33:49PM +0100, Christian Brauner wrote:
>>>> - first patch Feb 28 under pseudonym "techyguyperplexable", switched to "Josh Law" only when Andrew required a real name
>>>>   in https://lore.kernel.org/all/20260228114939.de7d44de38d907a9b6632480@linux-foundation.org
>>>> - 142+ emails in ~2 weeks ? 37 patches in a single day (Mar 1)
>>>> - All trivial/cosmetic ? SPDX headers, comment grammar, spacing, const qualifiers. Zero bug fixes, zero new functionality
>>>> - Carpet-bombed multiple subsystems ? lib/, arm64/, staging/, input/, etc.
>>>> - within 1 week of first-ever patch, submitted MAINTAINERS: add Josh Law as reviewer for library code covering all of lib/ (locking.c, iov_iter.c, rhashtable.c, etc.)
>>>> - Email identity mismatch ? From: hlcj1234567@gmail.com, Signed-off-by: objecting@objecting.org
>>>> - Formatting problems ? top-posting, line length violations, patches not applying cleanly
>>>>
>>>> So I mean, one week to Reviewer. Even if we're being very generous here,
>>>> we need to do a lot more due diligence going forward. We can't just hand
>>>> out core components like this and risking our reputation and security
>>>> posture.
>>>
>>> Thanks! Agree absolutely that we need to be careful about this. Jia Tan should
>>> be instructive.
>>>
>>> Josh - there's nothing personal here to be clear, this is a question of
>>> procedure and caution.
>>>
>>> More broadly I think we should avoid assigning new people to catch-all
>>> categories anyway unless they are well established enough to be involved with
>>> _everything_ the catch-all covers.
>>>
>>> For instance adding people to the mm/* other than perhaps... David ;) would be
>>> crazy.
>>>
>>> Also - Andrew - I think for cases where you are the only maintainer but it
>>> impacts others, you should seek acks proportional to the scope the MAINTAINERS
>>> entry spans - in this case that'd be a _lot_ of people - but that only
>>> underlines that we shouldn't be updating such entries anyway.
>>>
>>> In fact - can we just do away with catch-all's and just make sure MAINTAINERS
>>> entries are established for everything?
>>>
>>> I have ground to stand on for this as I personally did it for mm, although we do
>>> still have a catch-all (not sure if necessary any more?)
>>>
>>> In the case of lib/ a quick fix could be to figure out which files are not
>>> covered by other MAINTAINERS entries and adding them all to what is currently
>>> the catch-all?
>>>
>>> Cheers, Lorenzo
>>
>> Well, it's already been merged into linux-next, I will keep constantly
>
> That doesn't matter, lots of things end up temporarily in -next and
> disappear before it ever sees upstream.
>
>> trying to prove myself as a trusted figure in the community, and I am
>> learning new things every day about the rules, and when you talk about
>> me making "trivial" patches, I also made some medium sized bug fixes,
>> yeah my start was just "janitor" code, but I will try to prove myself,
>
> I have to agree with Christian/Lorenzo/et al here. This is not how it
> works. You prove yourself by doing quality work, and then and only then
> does it become official. Adding someone after 1 week of a bunch of
> trivial patches is literally crazy, imho.
>
> --
> Jens Axboe

Thank you guys for the context and the history. I understand now
why my request was premature and how it looks from a security and procedural
standpoint. I appreciate you taking the time to explain the 'Jia Tan'
caution, it makes total sense why the bar is so high.

I'm going to take the 'no rush' advice to heart. I'll focus on the technical
work, learn the etiquette, and prove myself through quality contributions over
time. Thank you for not being super mad


V/R


Josh Law