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

[David Hildenbrand (Arm)]

On 6/3/26 03:48, SeongJae Park wrote:
> On Tue, 2 Jun 2026 15:16:27 +0200 "David Hildenbrand (Arm)" <david@xxxxxxxxxx> wrote:
> 
>> On 6/2/26 15:08, Vlastimil Babka (SUSE) wrote:
>>>
>>> Well, as longs as there are no conflicts, it probably doesn't.
>>
>> Yes.
>>
>>>
>>>
>>> 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).
> 
> So I understand we agree we will allow peoplee to base their patches on
> whatever makes sense.  I like this flexibility.  The slight difference I show
> is that David suggests to use mm-next as the default baseline, and later rebase
> on subcomponent tree if needed.  Meanwhile, some subcomponent maintainers think
> the opposite direction make sense.  Submitter use the appropriate subcomponent
> maintainer-suggested tree as the default, and the submaintainers handle merge
> conflicts of their for-mm-next branch.

I assume, in practice, that people will do what they want either way (base on
Linus tree, linux-next etc), and it will be our job to see if it cleanly
applies, or ask for a proper resend.

I guess, as a first step, we'll document something similar to what TIP documents
in that regard.

> 
> I think both could work, and we will learn from trying.
> 
> But from a subcomponent maintainer's persepctive, I was thnking our process
> will be more like the second approach.  And I still slightly feeling that will
> be simpler for at least a subcomponent maintainer.  Why I feel so is like
> below.
> 
> In the first approach, as Vlastimil and David described already, there are
> chances of conflicts at picking mm-next based submitter's patch on subcomponent
> tree.  How frequenct and complex the conflicts will be is questionable.  But it
> feels like I will have to deal it with submitters.  E.g., asking rebase to
> submitters, like David mentioned.  I think some of submitters might not very
> familiar with git and the mm process, so I feel it might be not very simple
> always.
> 
> In the second appraoch, I expect less chances of conflicts when picking
> submitter patches on subcomponent trees.  The subcomponent maintainer will
> still get conflicts with mm-next and have to fix it.  But in this case, the
> subcomponent maintainer will be able to do that nearly alone.  Or, they will
> work with the mm-next maintainer and/or other subcomponent maintainers.  I
> pretty suree the other maintainers will be familiar with git and the process.
> So I expect less headaches.  Also, this kind of conflict resolving between
> subcomponent maintainer and mm-next trees is samely required for the first
> approach, anyway.

I'm sure we'll figure out how bad one approach or the other is as we move
forward, we can always adjust that. Conflicts will haunt us :)

But I assume, independent of what we document, we will always have people that
submit to arbitrary trees, and it will be out job to make sense of it (or ask to
resend).

Documentation is good, as long as people read it ...

> 
> mm-next maintainer's perspective might see many different things, though.  I
> will be more than glad to be learn what I'm missing and get enlightened.
> 
> Anyway I think both approaches may work, and we can learn from others and
> trying on our own.  I will be happy to help when there is something that I can
> help. :)

That's the right spirit! :)

We'll discuss this topic in more detail as we move forward!

-- 
Cheers,

David