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

["David Hildenbrand (Arm)" <david@kernel.org>]

On 6/1/26 18:16, Lorenzo Stoakes wrote:
> On Mon, Jun 01, 2026 at 05:45:30PM +0200, David Hildenbrand (Arm) wrote:
>> On 6/1/26 17:41, Lorenzo Stoakes wrote:
>>>
>>> I think life will be easier with submaintainer separate trees for this honestly
>>> :) or it could become a horrible mess in one tree I think.
>>
>> Requiring contributors to submit stuff targeted at some random trees is madness :)
> 
> 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 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?

This is likely something we'll have to play with to understand what is workable
and what not.

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

> 
> That sounds a lot more crazy to me, and I just don't think it's workable.
>>
>>>
>>> I think the simplest is what I suggested in reply to Vlasta, where each
>>> submaintainer tree has their own set of changes against mm-next/mm-stable and
>>> then we merge each week.
>>
>> Throw in hotfixes and it already starts being crazy.
> 
> Again I really don't understand this?
> 
> Hotfixes are a completely separate topic for one, I'm talking about ordinary
> development, but surely they're simpler aren't they?

I mean the interaction: new material that depend on hotfixes. Talking to Michal
and Vlastimil last week, there are some ways to make this work based on topic
branches (hotfixes being a topic branch IIUC), but I don't understand yet how
that works in detail, or how that would scale to subtrees.

> 
> Everything's based on Linus's tree (so no confusion as to which tree), there
> shouldn't (hopefully) be a huge amount of them, and submaintainers can just
> potentially find a way to send them direct to mm-next anyway?
> 
>>
>>>
>>> But am open to learning about what other subsystems in the kernel do...
>>
>> The TIP tree has a pretty elaborate model of dealing with topic branches, and
>> don't require things to be sent against specific topic branches.
>>
>> I'll try to understand that model.
> 
> OK well, interested to hear about that.
> 
> But also we should adapt what others do (which I think is very important to
> learn from obviously) against how mm works in practice.
> 
> High review load with many overlapping changes might favour a different approach
> to a subsystem that looks different from that.
Yeah, but as we said, we discussed, it's all rather complicated and we should
move incrementally.

-- 
Cheers,

David