Re: Process (was Re: [PATCH mm-hotfixes-unstable v18 00/14] khugepaged: add mTHP) collapse support

[David Hildenbrand (Arm)]

On 6/2/26 14:40, Lorenzo Stoakes wrote:
> On Tue, Jun 02, 2026 at 01:20:07PM +0200, David Hildenbrand (Arm) wrote:
>> On 6/1/26 18:16, Lorenzo Stoakes wrote:
>>>
>>> Err what? The 'random' tree is the MAINTAINERS entry you are targeting, it's
>>> based on the mm-next stable branch and only diverges in the work that's been
>>> done specific to the subtree, what's crazy exactly?
>>
>> We'll still have plenty of patch sets that touch files cross trees.
> 
> I'm not sure how keeping things in the same tree fixes anything though?

I think there is a misunderstanding. I am more thinking in terms of what the TIP
tree does, where you can send patches against the integration branch, or against
sub-branches that are maintained by sub-maintainers.

Terminology starts getting tricky.

> 
> You are just changing the _timing_ of when the conflicts happen at the cost
> of making things way more difficult to manage IMO.
> 
> I mean the reductio ad absurdum argument is why isn't all of linux in a
> single git tree? :)
> 
> If what you're saying is true it should be without issue? But I think there
> would be pretty huge issues...
> 
> And the disadvantage is now we have a bunch of sub-maintainers with write
> access to the key mm tree who could make mistakes and break things,
> hundreds of topic branches all bundled together, no separation between
> anything, and no sense of where anything's at.
> 
> If you're saying submaintainers manage topic branches (this cycle the ONE
> tree would have ~400 topic branches right? More if we included versions?)
> and then independently merge those into the mm-stable tree I think that's
> going to be a disaster in terms of timing/conflicts/etc.
> 
> And you're asking for conflict between submaintainers I think - what if one
> person merges his thing that then causes conflict for another etc. etc.
> 
> With separate trees then decisions can be made by the mm core people as to
> how to integrate, rather than people unilaterally doing whatever.
> 
> And if you're saying submaintainers won't do that, then essentially you're
> saying no submaintainer tree management at all :) which I think is a a bad
> idea for a subsystem as busy as mm.
> 
> I think mm is too large now to have everything under one person or a few
> people.
> 
> Separate trees implies division of labour, and then the integration tree
> can be more of a pure integration tree.

Just to clarify: I don't think everybody should have access to everything. I'm
currently trying to figure out which options we have.

TIP has everything in one tree (with sched/ x86/ ... name space sub-branches).

> 
>>
>> I don't see the problem of sending stuff against the integration tree from where
>> it can just be cleanly picked up by sub-maintainers (after all, that's where all
>> the subtrees were integrated against)? Or what exactly is the problem with that?
> 
> But what does 'picked up' mean? See above re: concerns.
> 
>>
>> This is likely something we'll have to play with to understand what is workable
>> and what not.
> 
> Actually, I think we have to decide early - because if you want
> submaintainers to test out this sub-tree or sub-branch? Or whatever thing
> it's very different asking them to:
> 
> - Create a new tree and do X, Y and Z to sync up with mm-next
> 
> Vs.:
> 
> - Have full write access to mm-next and create branches X, Y and Z and
>   merge things
> 

Right, let me figure what's actually possible so we can discuss if the
sub-branch model even makes sense.

>>
>>>
>>> I mean, is there any meaning to separate 'trees' at all if we just have one tree
>>> with topic branches in?
>>>
>>> Or are we going to have several parallel stable branches in one tree, and a
>>> bunch of maintainers with write access stepping on each other's toes?
>>
>> All valid question to which we don't have an answer yet. :)
> 
> :) I mean learning from how others do it is definitely key here.
> 
> Maybe we need to grill Brauner?

Yes, already reached out :)


-- 
Cheers,

David