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

[Lorenzo Stoakes <ljs@kernel.org>]

On Mon, Jun 01, 2026 at 05:45:30PM +0200, David Hildenbrand (Arm) wrote:
> On 6/1/26 17:41, Lorenzo Stoakes wrote:
> > On Sun, May 31, 2026 at 09:49:02PM +0200, David Hildenbrand (Arm) wrote:
> >>>
> >>>
> >>> This I'm not so sure how it would work. Assuming we have submaintainers with
> >>> their trees and branches, the final "stable branch" is merged from those.
> >>> But it's not a good base for work targeting the same merge window, as that
> >>> work would likely go to one of those submaintainer trees. But then it can't
> >>> be based on the result of merge of all submaintainer trees. That could only
> >>> work for patches targetting the next cycle (after the stable branch becomes
> >>> part of rc1).
> >>>
> >>> So either patches can be based on rc1 and applied as topic branches in a
> >>> submaintainer tree and then merged, or if they really depend on something
> >>> already in a submaintainer tree, then based on the respective topic branch
> >>> that's part of it.
> >>
> >> Right, most patches can be sent against the "stable branch", but cherry-picked
> >> on a submaintainers branch / topic tree.
> >
> > I think life will be easier with submaintainer separate trees for this honestly
> > :) or it could become a horrible mess in one tree I think.
>
> Requiring contributors to submit stuff targeted at some random trees is madness :)

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?

I mean, is there any meaning to separate 'trees' at all if we just have one tree
with topic branches in?

Or are we going to have several parallel stable branches in one tree, and a
bunch of maintainers with write access stepping on each other's toes?

That sounds a lot more crazy to me, and I just don't think it's workable.
>
> >
> > I think the simplest is what I suggested in reply to Vlasta, where each
> > submaintainer tree has their own set of changes against mm-next/mm-stable and
> > then we merge each week.
>
> Throw in hotfixes and it already starts being crazy.

Again I really don't understand this?

Hotfixes are a completely separate topic for one, I'm talking about ordinary
development, but surely they're simpler aren't they?

Everything's based on Linus's tree (so no confusion as to which tree), there
shouldn't (hopefully) be a huge amount of them, and submaintainers can just
potentially find a way to send them direct to mm-next anyway?

>
> >
> > But am open to learning about what other subsystems in the kernel do...
>
> The TIP tree has a pretty elaborate model of dealing with topic branches, and
> don't require things to be sent against specific topic branches.
>
> I'll try to understand that model.

OK well, interested to hear about that.

But also we should adapt what others do (which I think is very important to
learn from obviously) against how mm works in practice.

High review load with many overlapping changes might favour a different approach
to a subsystem that looks different from that.

>
> --
> Cheers,
>
> David

Thanks, Lorenzo