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

[SeongJae Park]

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

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

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


Thanks,
SJ

[...]