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

From: David Hildenbrand (Arm)

Date: Mon Jun 01 2026 - 11:46:10 EST


On 6/1/26 17:41, Lorenzo Stoakes wrote:
> On Sun, May 31, 2026 at 09:49:02PM +0200, David Hildenbrand (Arm) wrote:
>>>
>>>
>>> This I'm not so sure how it would work. Assuming we have submaintainers with
>>> their trees and branches, the final "stable branch" is merged from those.
>>> But it's not a good base for work targeting the same merge window, as that
>>> work would likely go to one of those submaintainer trees. But then it can't
>>> be based on the result of merge of all submaintainer trees. That could only
>>> work for patches targetting the next cycle (after the stable branch becomes
>>> part of rc1).
>>>
>>> So either patches can be based on rc1 and applied as topic branches in a
>>> submaintainer tree and then merged, or if they really depend on something
>>> already in a submaintainer tree, then based on the respective topic branch
>>> that's part of it.
>>
>> Right, most patches can be sent against the "stable branch", but cherry-picked
>> on a submaintainers branch / topic tree.
>
> 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 :)

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

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

--
Cheers,

David