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