Re: [MAINTAINERS SUMMIT] Any feedback for -next?

On Wed, Aug 12, 2026 at 01:19:05PM +0200, Uwe Kleine-König wrote:
> On Tue, Aug 11, 2026 at 05:54:59PM +0100, Mark Brown wrote:

> > Any other ideas?

> One thing I recently wondered is if it would make sense to not merge one
> tree after another into the same tree, but first create pairs, then
> merge two pairs, ...

> The advantage is that if commit B breaks something there are less
> intermediate trees that don't contain B and you can still test on e.g.
> D+E.

> I'm not convinced the advantages outweight the additional effort, but
> IMHO this is a bit similar to the request by the filesystem guys to have
> a tree with only filesystem changes.

> So this is just an idea that might be worth to be thought about by more
> than just me.

Yeah, there was also Sasha was talking about something with trying to
make loosely topic based subtrees.  As you mention there's a scripting
and comprehensibility cost to doing something like this, both when
building the tree and when trying to understand the results.  If people
actually want the intermediate trees directly like with the filesystems
stuff then sure, but if there's no demand for the specific combinations
of trees I'm not sure it's worth it.

There's also the issue of incremental build benefits.

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmp8oUkACgkQJNaLcl1U
h9D3NQf/aScGH0r1a5PEx5bUto3Ma98X94kl9y8Itae3xkOaeQsSqSW3j2QoztmS
w+XXsCH8DFOaNpvN9G8hw1mya6XfjJYEtFdHe1x+HDxFRoVFPhn5OKYCX7mr918N
q+3rPhX+VDSo6KnmqbCzuSMlGY8rkHC90EI7Xu+k3SgNhhNTBnyG+EhlnMWYChJC
KhtDkgtBjMkjDzEl3mXdwLFLiQEbgHUAp7VrofBx0900vNG8OExHHqtdrUJS8lbQ
W3SCPrc6HsjHT5avvNh48vcOImKhJhtMuCMFVHGQ38IfDQJEepfzCsElg1WHFP/g
Lr6FzVm3i6PFoez01vl5rAj5KLyzqw==
=9ldW
-----END PGP SIGNATURE-----