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

["Uwe Kleine-König" <u.kleine-koenig@baylibre.com>]

[-- Attachment #1: Type: text/plain, Size: 3544 bytes --]

Hello Geert,

On Thu, Aug 13, 2026 at 09:31:58AM +0200, Geert Uytterhoeven wrote:
> On Wed, 12 Aug 2026 at 18:44, Mark Brown <broonie@debian.org> wrote:
> > 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 thing everybody understood, but for the record: s/don't // in the
above paragraph.

> 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 initially thought this to be an advantage, too, but I think that to be
wrong. Also in linear mode you're able to find a tree that is roughly in
the middle between good and bad.

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

That happens if you declared linus/master to be good and maintainer
trees are based on older commits in Linus's tree. Then with linus/master
(say at 7.2-rc7) being good and (say) m68k (say based on 7.2-rc1) being
bad the two possibilities are that m68k broke something or that 7.2-rc1
was already bad and a commit between -rc1 and -rc7 repaired it.

> > There's also the issue of incremental build benefits.
> 
> That should be more or less the same as before.

Look at my example. For the (let's call it) linear mode that is
currently in use the creator of next has to test:

 - base + B			(new subtree to build: B)
 - base + B + C			(new subtree to build: C)
 - base + B + C + D		(new subtree to build: D)
 - base + B + C + D + E		(new subtree to build: E)

So it's four builds and every time the delta is only a single tree and
for each maintainer tree you only have to build once without that tree
and once with it

With the (let's call it) binary tree mode you have to test:

 - B + C			(new subtree to build: B + C)
 - D + E			(new subtree to build: oldB + oldC + D + E)
 - B + C + D + E		(new subtree to build: B + C)

That is one merge (and thus one build test) less, but you have to build
8 subtrees compared to 4 in linear mode.

Additionally my demo tree assumed that all trees base on base (= Linus's
master branch), which in general isn't true and thus you need to
consider that as an input tree, too. Let's say Linus's tree is B, as
it's special maybe create

	B + x for x in { C, D, E }

first increasing the effort still more. Otherwise half of the trees
"hit" linus/master only in the last step (and all together), which
somehow defeats the purpose of next and also without lifting all trees
to linus/master first, the difference between "B + C" and "D + E" might
still be bigger than just the four subtrees.

> After all you're building the same number of times, it's just the
> changes that are reshuffled.

So yes, the number of builds is in the same order, but the rebuild
effort is higher in each build.

> And you do use ccache, I hope?

Yes, ccache helps, but it's still more expensive than not having to
build at all.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]