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

[Mark Brown]

On Wed, Jun 03, 2026 at 07:48:46AM +0100, Lorenzo Stoakes wrote:
> On Tue, Jun 02, 2026 at 08:31:42PM +0300, Mike Rapoport wrote:
> > * 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.

> I won't yell :) but I really don't want us to do this, and to improve our
> testing locally. Because:

> - We've become a bit notorious for breaking linux-next

TBH I can't say I've registered that with either of my running linux-next
or my testing hats on.  Considering the scope of what ends up in the mm
tree it's not particularly concerning, and it's very rare for there to be
anything so catastrophically bad at runtime that it causes unreasonable
disruption.  Importantly when there are issues they tend to get addressed
promptly with either a fix or dropping the offending code as far as I can
see, that's key for -next.

If you're looking at -next you're looking to provide early testing so
breakage is expected, there's a balance with making an effort to ensure
that you don't make too much noise for people doing testing and especially
avoiding causing too much breakage which means things don't run at all.

Of course having written the above there's a -mm build failure today.

> - It makes it more difficult for us to yank things

FWIW I can easily add extra trees to -next, and there's the option of
doing something like the fs-current and fs-next branches in -next ATM
where I do submerges consisting of only the various filesystem trees
which are published separately so they can be used for filesystem
specific testing.  There's several areas where integration trees require
their subtrees to be in -next directly for a bit before they get merged
into the integration tree.

Attachment: signature.asc
Description: PGP signature