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

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

On 6/2/26 14:47, Vlastimil Babka (SUSE) wrote:
> On 6/2/26 13:20, 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 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?
> 
> The problem is that the patches would not be applied on top of the
> integration tree, so it doesn't make sense to base them on it in the first
> place. Unless they target the next cycle, where the integration tree would
> first become part of rc1, which would be the new base for all the
> submaintainer trees.
Why does that matter?

For example, the slab-next tree gets merged into the mm-next tree. Submitter
will send against mm-next.

The slab maintainer will cherry-pick the patches on top of slab-next. From where
they end up in mm-next.

In the rare event of conflicts, the base-commit ID is there and known. If it's
too much of a mess, we could ask to resend against the slab-next tree.

Again, TIP allows that. For example, I never based any x86/mm patch on x86/mm
and ... was fine? :)

-- 
Cheers,

David