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

[Mike Rapoport <rppt@kernel.org>]

On Tue, Jun 02, 2026 at 02:55:30PM +0200, Vlastimil Babka (SUSE) wrote:
> On 6/2/26 13:31, David Hildenbrand (Arm) wrote:
> >>> 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.
> >> Yeah, but as we said, we discussed, it's all rather complicated and we should
> >> move incrementally.
> >> 
> > 
> > Starting to read Documentation/process/maintainer-tip.rst, it's very interesting:
> > 
> > “The tip tree is both a direct development tree and and an aggregation tree for
> > several sub-maintainer trees.”
> > 
> > “In general, development against the head of the tip tree master branch is fine,
> 
> I don't think we'll be able to use this part as mm-next will be only an
> aggreggation tree and not also a direct development tree.
> 
> > but for the subsystems which are maintained separately, have their own git tree
> > and are only aggregated into the tip tree, development should take place against
> > the relevant subsystem tree or branch.”
> 
> So it would have to be this.
> As it might be hard for contributors to pick the right one (as Lorenzo
> pointed out), we might in general suggest they try developing against rc1
> first (which is the common base of all subsystem trees), then either it
> applies to one of the subsystem trees as-is, or it applies as a topic branch
> (which starts also on the rc1 base) with reasonable conflict resolution
> during merge, or we tell them which exising subtree/branch to rebase on.

Unless we carry semi-baked work through merge window *, at rc1 all trees
anyway restart the cycle.

So basing new work on rc1 is very reasonable choice. Once that work is
merged it will be merged to a particular sub-tree. Even patchsets that
touch files across the trees still will be merged to a single sub-tree.
And once a patches is merged it's clear what should be the base for the
work that builds on top of that patchest.

Obviously there would be conflicts when sub-trees are merged into the
integration tree, but that's maintainers responsibility to resolve them
IMHO.

* Supposing we keep the model of early merging for testing [Lorenzo, don't
yell at me ;-)] I think it's reasonable enough to drop everything that's
not going upstream at, say, rc6 and ask contributors to rinse and repeat
after rc1.

> > “Bug fixes which target mainline should always be applicable against the
> > mainline kernel tree. Potential conflicts against changes which are already
> > queued in the tip tree are handled by the maintainers.”
> 
> Ack.

+1

-- 
Sincerely yours,
Mike.