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