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

Mark Brown <[email protected]> Thu, 13 Aug 2026 13:36:34 +0100

Newsgroups	org.kernel.vger.linux-next,dev.linux.lists.ksummit
Message-ID	<[email protected]>

On Thu, Aug 13, 2026 at 09:31:58AM +0200, Geert Uytterhoeven wrote:
> On Wed, 12 Aug 2026 at 18:44, Mark Brown <[email protected]> wrote:

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

> Sounds like a nice idea to me!
> And you can put the trees that usually cause the most conflicts in
> the same subgroup ;-)

> It may also help in bisecting an issue.  I have the impression "git
> bisect" on linux-next (against Linus' tree, not against yesterday's
> next) shows me more "a merge base must be tested" test points than
> expected/optimal.

IME it tends to walk down the linear history of -next until it find
which branch introduced the regression.  I've never investigated in
detail but my feeling is that the inefficiency is more driven by the
size of the branch it lands on.

> > There's also the issue of incremental build benefits.

> That should be more or less the same as before. After all you're
> building the same number of times, it's just the changes that are
> reshuffled. And you do use ccache, I hope?

No ccache, it was enabled in the past but it got turned off by Stephen,
I suspect the reuse over what you get from just doing incremental builds
is questionable.  We did have mediocre experiences with it on KernelCI
too.

The thing isn't just the number of builds, it's how often those builds
change headers that trigger full rebuilds, and we're only sampling the
builds rather than actually doing every single one so that the merge
completes in a viable amount of time.  That might miss stuff, but due to
the way trees are ordered it will likely be only things that will get
resolved before they go anywhere near Linus anyway.

signature.asc (application/pgp-signature, 488 B)