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

[Vlastimil Babka (SUSE)]

On 6/2/26 14:58, David Hildenbrand (Arm) wrote:
> 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?

Well, as longs as there are no conflicts, it probably doesn't.

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

Note slab-next itself might be a collection of topic branches and it might
be more flexible to create another topic branch (based on rc1) and merge it,
than apply stuff on top of a product of merging.

(I think extreme case if vfs where almost everything is topic branch and
even the PRs to Linus are many separate branches?)

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

Alright, I guess some conflicts might be harder to resolve when based on
mm-next and then tried to rebase on slab-next only. And others harder to
resolve when based on rc1 and then integrated to slab-next.

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