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

[Josh Law <hlcj1234567@gmail.com>]

13 Mar 2026 15:52:54 Darrick J. Wong <djwong@kernel.org>:

> On Fri, Mar 13, 2026 at 04:33:49PM +0100, Christian Brauner wrote:
>> On Fri, Mar 13, 2026 at 04:00:38PM +0100, Christian Brauner wrote:
>>> On Sat, Mar 07, 2026 at 10:19:31PM +0000, Josh Law wrote:
>>>> Add myself as a designated reviewer for the library code to help review
>>>> incoming patches and improvements.
>>>>
>>>> Signed-off-by: Josh Law <objecting@objecting.org>
>>>> ---
>>>> MAINTAINERS | 1 +
>>>> 1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>> index 96e97d25e1c2..8fd03ab9c657 100644
>>>> --- a/MAINTAINERS
>>>> +++ b/MAINTAINERS
>>>> @@ -14613,6 +14613,7 @@ F:  tools/testing/nvdimm/
>>>>
>>>> LIBRARY CODE
>>>> M: Andrew Morton <akpm@linux-foundation.org>
>>>> +R: Josh Law <objecting@objecting.org>
>>>> L: linux-kernel@vger.kernel.org
>>>> S: Supported
>>>> T: git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-nonmm-unstable
>>>> --
>>>> 2.43.0
>>>>
>>>
>>> On Fri, Mar 13, 2026 at 10:17:53AM +0000, Lorenzo Stoakes (Oracle) wrote:
>>>> On Sat, Mar 07, 2026 at 10:19:31PM +0000, Josh Law wrote:
>>>>> Add myself as a designated reviewer for the library code to help review
>>>>> incoming patches and improvements.
>>>>>
>>>>> Signed-off-by: Josh Law <objecting@objecting.org>
>>>>
>>>> Sorry but NAK, I appreciate your enthusiasm but this is literally _all_
>>>> library code, and you don't have a long track history in the kernel.
>>>>
>>>> Also in [0], [1], etc. you aren't demonstrating a great deal of maturity,
>>>> so I don't think it's appropriate for you to be added at this time.
>>>>
>>>> I really don't think a 'catch all' category should be getting arbitrary
>>>> extra reviewers in any case.
>>>>
>>>> Please take some time to contribute to the kernel, establish yourself, and
>>>> then look to reviewership for a specific category.
>>>>
>>>> Thanks, Lorenzo
>>>>
>>>>> ---
>>>>> MAINTAINERS | 1 +
>>>>> 1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>>> index 96e97d25e1c2..8fd03ab9c657 100644
>>>>> --- a/MAINTAINERS
>>>>> +++ b/MAINTAINERS
>>>>> @@ -14613,6 +14613,7 @@ F:  tools/testing/nvdimm/
>>>>>
>>>>> LIBRARY CODE
>>>>> M: Andrew Morton <akpm@linux-foundation.org>
>>>>> +R: Josh Law <objecting@objecting.org>
>>>>> L: linux-kernel@vger.kernel.org
>>>>> S: Supported
>>>>> T: git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-nonmm-unstable
>>>>> --
>>>>> 2.43.0
>>>>>
>>>>>
>>>>
>>>> [0]:https://lore.kernel.org/all/c41dbb9d-b8a5-4b5f-9f71-3fe1bed210b6@gmail.com/
>>>> [1]:https://lore.kernel.org/linux-mm/40767ecf-7e25-48f5-a604-c43b835b6b66@gmail.com/
>>>
>>> On Fri, Mar 13, 2026 at 11:49:03AM +0100, Vlastimil Babka wrote:
>>>> On 3/13/26 11:17, Lorenzo Stoakes (Oracle) wrote:
>>>>> On Sat, Mar 07, 2026 at 10:19:31PM +0000, Josh Law wrote:
>>>>>> …
>>>>>
>>>>> Sorry but NAK, I appreciate your enthusiasm but this is literally _all_
>>>>> library code, and you don't have a long track history in the kernel.
>>>>
>>>> Agreed, just a week after first appearance on lists is really quite too soon.
>>>>
>>>> Yes, getting Cc'd thanks to R: entry is one thing, but that can be achieved
>>>> with lei as well. The other aspect of R: is giving weigh in replies to
>>>> (potentially new) contributors and that's why it's not given out rather that
>>>> quickly.
>>>>
>>>>> Also in [0], [1], etc. you aren't demonstrating a great deal of maturity,
>>>>> so I don't think it's appropriate for you to be added at this time.
>>>>>
>>>>> I really don't think a 'catch all' category should be getting arbitrary
>>>>> extra reviewers in any case.
>>>>
>>>> Agreed. Many of the files under lib/ are listed in other sections with their
>>>> own maintainers. They were not cc'd on this MAINTAINERS update and yet it
>>>> would affect all patches to their files too, so they could at least have a
>>>> say. It's unfortunate that it's how this catch-all works. Maybe X: entries
>>>> could be used by the specific maintainers in the catch-all section, although
>>>> it's somewhat tedious.
>>>
>>> Agreed. I'm sorry but there is no meaningful track record that would
>>> justify this addition. lib/ encompasses locking.c, iov_iter.c,
>>> rhashtable.c and a ton of other stuff that is consumed by literally the
>>> whole kernel from core to drivers. If this was something innocous I
>>> wouldn't care but there's a lot of really gnarly but important stuff in
>>> there.
>>>
>>> And yes, all of the externally maintained files should be dropped from
>>> the generic lib/ catch-all ideally.
>>
>> Ok, so let's look at this for a minute:
>>
>> - 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.
>
> /me sees "Lmao you and your test cases" in [1] and responds with "LMAO
> NAK".  If you're not serious about helping everyone to test your changes
> to library code such that you respond that dismissively to longtime
> maintainers, you shouldn't be working on operating system kernels.
>
> --D

I apologize unreservedly to the maintainers and the community. The
comment I made was incredibly disrespectful and immature. I realize now that
testing is foundational to kernel development, especially in library
code, and my dismissive response was a massive failure on my part.

I have a lot to learn about the technical requirements of the kernel,
but clearly, I have even more to learn about the professional
standards of this community. I accept the NAK and will step back to
re-evaluate my approach and conduct. I am sorry for wasting your time.


V/R


Josh Law