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

[Christian Brauner]

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@xxxxxxxxxxxxx>
> > ---
> >  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@xxxxxxxxxxxxxxxxxxxx>
> > +R:	Josh Law <objecting@xxxxxxxxxxxxx>
> >  L:	linux-kernel@xxxxxxxxxxxxxxx
> >  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@xxxxxxxxxxxxx>
> > 
> > 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@xxxxxxxxxxxxxxxxxxxx>
> > > +R:	Josh Law <objecting@xxxxxxxxxxxxx>
> > >  L:	linux-kernel@xxxxxxxxxxxxxxx
> > >  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@xxxxxxxxx/
> > [1]:https://lore.kernel.org/linux-mm/40767ecf-7e25-48f5-a604-c43b835b6b66@xxxxxxxxx/
> 
> 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:
> > >> Add myself as a designated reviewer for the library code to help review
> > >> incoming patches and improvements.
> > >>
> > >> Signed-off-by: Josh Law <objecting@xxxxxxxxxxxxx>
> > > 
> > > 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@xxxxxxxxxxxxxxxxxxxx
- 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@xxxxxxxxx, Signed-off-by: objecting@xxxxxxxxxxxxx
- 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.