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

["Vlastimil Babka (SUSE)" <vbabka@kernel.org>]

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.

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

> So, yeah, let me reach out to understand what works, what doesn't work, and how
> it works :)
>