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

[Christian Brauner <brauner@kernel.org>]

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:
> >> 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.
> 
> 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.