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

[David Hildenbrand (Arm)]

On 6/2/26 15:08, Vlastimil Babka (SUSE) wrote:
> On 6/2/26 14:58, David Hildenbrand (Arm) wrote:
>> On 6/2/26 14:47, Vlastimil Babka (SUSE) wrote:
>>>
>>> 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.

Yes.

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

Right, and I assume that the maintainer would then either try to fix it up
himself, or ask the submitter to base against a specific branch. (e.g., against
another topic branch etc).

I assume one can go crazy with topic branches. Fortunately, we can do that
incrementally IIUC.

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

Yes, that's also one thing TBD.

-- 
Cheers,

David