[LSF/MM/BPF TOPIC] MM transition

[LSF/MM/BPF TOPIC] MM transition

[Andrew Morton]

Hi, all.  Some things I'd like to discuss in the "MM process" slot at
LSFMM.

I wish to start unwinding my MM involvement.  Because I'd like to be
able to retire one day.  And because things feel excessively
concentrated - I'm doing too much stuff, others have valuable views. 
I'm healthy (enough), plenty motivated and my mind is still sharp
(shaddup) but bad things happen to 67 year olds and they can happen
swiftly.

I want this this transition to be gradual, orderly and incremental - no
sudden changes.  Give ourselves about one year to do one thing at a time,
re-evaluate at each step, make alterations if needed, on to the next step.
Of course, we have our ongoing mm/ development work and let's avoid
disrupting that.


The model I wish to move towards is a more conventional top-level
integration tree (working title "mm-next") which pulls together N
component[1] trees.  mm-next is the usual source of our mm->linus
pulls.  mm-next will have a hotfixes branch for that material which
we're fast-tracking upstream.

David Hildenbrand has kindly agreed to set up and operate mm-next and I
hope/expect that David will take a leading role in this transition.  

("mm-next" isn't really an appropriate name, but mm.git is being a
namespace hog - some renaming might be needed)

mm-next will initially contain mm.git and, I hope, any other git trees
we can find.  slab and memblock at least temporarily, if Vlastimil and
Mike are agreeable.  I want other trees in there apart from mm.git so
the tooling, processes etc can be worked out.  An "aggregation" tree
which aggregates a single tree is a bit silly.

Once mm.next is up and operating and the pulls are flowing smoothly, let's
introduce one other tree.  This might be "vma" from that component's
maintainers.  Then another tree and so on.  So mm.git gets smaller and
smaller.

I expect that as the backup catchall, mm.git will always have a
significant amount of material.  It will continue to act as a hosting
service for Maintainers who don't wish to operate their own tree.  MM has
~38 listed M:aintainers; many of these parts are small, with low change
rates and M:aintainers have differing levels of engagement, and that's
fine.  Also, there are parts with no identifiable maintainer, some
maintainers will sometimes be unavailable, etc.  Also those little changes
which nobody feels inclined to look at.  MM will continue to need a team
Mom.

I plan to keep running the mm-nonmm branches.  Kernel-wide team Mom - it's
pretty quiet.  And maybe mm.git if it's small enough, if I'm not getting
in the way and if I can't find a sucker^Wkind person to take it over.

For this discussion and in the upcoming meeting please let's not get too
far down into the weeds of tree structures, workflow, individual's roles,
etc.  At this time let's focus on the final implementation and upon my
plan to get from here to there, then we can discuss details.  David will
be hosting some "transition workgroup" meetings after LSFMM to further
these matters.

Thanks.

[1] Terminology: MM is a subsystem of Linux, so the various MM
    subsystems are really subsubsystems.  Confusing!  I propose that we
    Not Do That, and start referring to the various parts of MM as
    "components".  So mm-next aggregates component trees.

Re: [LSF/MM/BPF TOPIC] MM transition

[Josh Law]

Hello, since I'm not coming to LSF/BPF because of my age (aw)

(And I'm more than aware this post is more mm focused, but I'm
representing lib :))

I'm "virtually" putting my hand up


Whats going to happen to lib/?

I'm aware there are submaintainers for some files

E.G: Steven (and Petr) for vsprintf
Masami for bootconfig
Willy for idr 
Liam for maple tree
Etc

But let's say, lib/glob.c, or lib/bug.c, even lib/inflate.c! (And/or 
all files which only has you set as primary maintainer)

get_maintainers.pl says just you!

If you retire, let's say, then the files will be orphaned, idk what
you want to do with these files.

Thanks! :-)

Re: [LSF/MM/BPF TOPIC] MM transition

[David Hildenbrand (Arm)]

On 4/21/26 21:25, Josh Law wrote:
> Hello, since I'm not coming to LSF/BPF because of my age (aw)
> 
> (And I'm more than aware this post is more mm focused, but I'm
> representing lib :))
> 
> I'm "virtually" putting my hand up
> 
> 
> Whats going to happen to lib/?
> 
> I'm aware there are submaintainers for some files
> 
> E.G: Steven (and Petr) for vsprintf
> Masami for bootconfig
> Willy for idr 
> Liam for maple tree
> Etc
> 
> But let's say, lib/glob.c, or lib/bug.c, even lib/inflate.c! (And/or 
> all files which only has you set as primary maintainer)

I'd assume that (excluding MM bits, for example) falls in the foreseeable future
under the "I plan to keep running the mm-nonmm branches.".

What happens when Andrew fully retires is a probably a good question for the
future :)

-- 
Cheers,

David

Re: [LSF/MM/BPF TOPIC] MM transition

[Josh Law]

On 22 April 2026 19:18:25 BST, "David Hildenbrand (Arm)" <david@kernel.org>
wrote:
>On 4/21/26 21:25, Josh Law wrote:
>> Hello, since I'm not coming to LSF/BPF because of my age (aw)
>> 
>> (And I'm more than aware this post is more mm focused, but I'm
>> representing lib :))
>> 
>> I'm "virtually" putting my hand up
>> 
>> 
>> Whats going to happen to lib/?
>> 
>> I'm aware there are submaintainers for some files
>> 
>> E.G: Steven (and Petr) for vsprintf
>> Masami for bootconfig
>> Willy for idr 
>> Liam for maple tree
>> Etc
>> 
>> But let's say, lib/glob.c, or lib/bug.c, even lib/inflate.c! (And/or 
>> all files which only has you set as primary maintainer)
>
>I'd assume that (excluding MM bits, for example) falls in the foreseeable
>future
>under the "I plan to keep running the mm-nonmm branches.".
>
>What happens when Andrew fully retires is a probably a good question for
>the
>future :)
>
>

Yeah David. True, but nobody lasts forever. Andrew is "stupidly busy" (his
words ;D), so the (basically) orphaned files like glob, or smth like that,
could go to someone who understands the code better and more likely than
not, has time to review.

We may have to have a think about this.

Re: [LSF/MM/BPF TOPIC] MM transition

[David Hildenbrand (Arm)]

On 4/22/26 20:22, Josh Law wrote:
> On 22 April 2026 19:18:25 BST, "David Hildenbrand (Arm)" <david@kernel.org>
> wrote:
>> On 4/21/26 21:25, Josh Law wrote:
>>> Hello, since I'm not coming to LSF/BPF because of my age (aw)
>>>
>>> (And I'm more than aware this post is more mm focused, but I'm
>>> representing lib :))
>>>
>>> I'm "virtually" putting my hand up
>>>
>>>
>>> Whats going to happen to lib/?
>>>
>>> I'm aware there are submaintainers for some files
>>>
>>> E.G: Steven (and Petr) for vsprintf
>>> Masami for bootconfig
>>> Willy for idr 
>>> Liam for maple tree
>>> Etc
>>>
>>> But let's say, lib/glob.c, or lib/bug.c, even lib/inflate.c! (And/or 
>>> all files which only has you set as primary maintainer)
>>
>> I'd assume that (excluding MM bits, for example) falls in the foreseeable
>> future
>> under the "I plan to keep running the mm-nonmm branches.".
>>
>> What happens when Andrew fully retires is a probably a good question for
>> the
>> future :)
>>
>>
> 
> Yeah David. True, but nobody lasts forever. Andrew is "stupidly busy" (his
> words ;D), 

Yes, but he also writes (nonmm) "it's pretty quiet" ;)

So, MM is the real struggle.

> so the (basically) orphaned files like glob, or smth like that,
> could go to someone who understands the code better and more likely than
> not, has time to review.
> 
> We may have to have a think about this.

I'm sure

(a) Andrew will enjoy being around and we will enjoy having Andrew around.
(b) If Andrews workload is still too high, even after MM is handled differently,
    or when he wants to completely retire, I'm sure he will speak up.

One step at a time.

-- 
Cheers,

David

Re: [LSF/MM/BPF TOPIC] MM transition

[Josh Law]

[Snip! :)]

>
>Yes, but he also writes (nonmm) "it's pretty quiet" ;)
>
>So, MM is the real struggle.
>
>> so the (basically) orphaned files like glob, or smth like that,
>> could go to someone who understands the code better and more likely than
>> not, has time to review.
>> 
>> We may have to have a think about this.
>
>I'm sure
>
>(a) Andrew will enjoy being around and we will enjoy having Andrew around.
>(b) If Andrews workload is still too high, even after MM is handled
>differently,
>    or when he wants to completely retire, I'm sure he will speak up.
>
>One step at a time.
>
>

Agreed. If he needs help reviewing patches in lib, he can feel free to
CC: me, best I can do showing he helped me when I first started :)

I'll enjoy having Andrew review my patches, he's one of the most polite
maintainers apparently.

that's why lib/ is my favourite directory!

Re: [LSF/MM/BPF TOPIC] MM transition

[Matthew Wilcox]

On Tue, Apr 21, 2026 at 08:25:24PM +0100, Josh Law wrote:
> Hello, since I'm not coming to LSF/BPF because of my age (aw)

What is this nonsense?  You aren't coming to LSFMM because you haven't
requested an invitation.  If you had requested an invitation, you would
have been rejected (because we have limited seats and there are people
who are far more qualified than you who did not get an invitation).

You already have a reputation as a liar [1].  Don't compound it.  At this
point I've tentatively assigned to you some other nasty character traits.

[1] https://lore.kernel.org/linux-mm/cea99016-5407-4392-9b7d-2e6a994f550f@lucifer.local/

> (And I'm more than aware this post is more mm focused, but I'm
> representing lib :))

No.  You're not.  You sent a presumptive patch adding yourself as lib
reviewer, and that was also rejected.  You don't have what we're looking
for in a maintainer, and you're starting from rather further behind than
somebody with no record.

Re: [LSF/MM/BPF TOPIC] MM transition

[Josh Law]

On 22 April 2026 20:03:33 BST, Matthew Wilcox <willy@infradead.org> wrote:
>On Tue, Apr 21, 2026 at 08:25:24PM +0100, Josh Law wrote:
>> Hello, since I'm not coming to LSF/BPF because of my age (aw)
>
>What is this nonsense?  You aren't coming to LSFMM because you haven't
>requested an invitation.  If you had requested an invitation, you would
>have been rejected (because we have limited seats and there are people
>who are far more qualified than you who did not get an invitation).

Sorry. Yeah, didn't realise till I googled it.


>You already have a reputation as a liar [1].  Don't compound it.  At this
>point I've tentatively assigned to you some other nasty character traits.
>
>[1]
>https://lore.kernel.org/linux-mm/cea99016-5407-4392-9b7d-2e6a994f550f@lucifer.local/

The "bot" thing has been disproven [1]

About the whole trust thing. I'm working hard to get that back, sorry
but no need to be harsh.

I'm working with Steven here to try and handle the social side, bare
with me here since I'm not perfect

[1]:
https://lore.kernel.org/all/20260402093410.040423b1@gandalf.local.home/

>> (And I'm more than aware this post is more mm focused, but I'm
>> representing lib :))
>
>No.  You're not.  You sent a presumptive patch adding yourself as lib
>reviewer, and that was also rejected.  You don't have what we're looking
>for in a maintainer, and you're starting from rather further behind than
>somebody with no record.

No, not in the maintainer way. As in like me being patriotic for the
directory 

Let's please please please not cause a argument here. We can agree to
disagree on things. 

(Cc: rostedt@goodmis.org because I said his name.)


Thanks!