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

Geert Uytterhoeven <[email protected]>
Newsgroups org.kernel.vger.linux-next,dev.linux.lists.ksummit
Message-ID <CAMuHMdVEejuG-Dyr4DXgg3MhtDY6n5cDYPotRiGXeSGv0AcA+g@mail.gmail.com>
Hi Mark,

On Wed, 12 Aug 2026 at 18:44, Mark Brown <[email protected]> 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.

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.

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

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.