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

On 8/13/26 14:36, Mark Brown wrote:
> 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.

When bisecting -next, I actually use the "git bisect --first-parent" mode
first explicitly to find the culprit branch (or precisely, its merge), then
do a second bisect only within it. It avoids wild changes of the tree
between bisection steps due to the differing bases.

The suggested binary tree merging approach would make this strategy somewhat
more difficult.

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