[MAINTAINERS SUMMIT] Any feedback for -next?

[MAINTAINERS SUMMIT] Any feedback for -next?

[Mark Brown]

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

Hi,

I was reminded by some of the maintainers summit threads that it would
be a good idea to check in about how things are going with -next and if
anyone has any ideas for things that could be done better.  I've flagged
this as a maintainers summit topic just in case but I think it's quite
probably more of a list thing.

Mostly it's been business as usual, hopefully I'll get better at doing
merges as time goes on.  That said the list of visible changes I wrote
seems a bit long:

 - We in theory now do rust builds (at least when all*config enable it,
   hopefully that get fixed soon[1]), given that rust things need merge
   fixups and rust is now a normal feature this seems obviously useful.

 - We now do KUnit runs as part of the builds with KASAN enabled, this
   has been quite useful for keeping memory corruption and severe boot
   break issues out of -next I think.  Prior to enabling KASAN it would
   often flag on a different tree to the one that was causing issues
   which wasn't so useful but KASAN seems to have done the trick there.

 - We now cover a subset of the kselftests, this does find issues
   moderately often and helps keep CI coverage.

 - Started sending out a weekly summary of the state of the world -
   perhaps there's extra stuff I could be adding in there?

 - Removed one tree that was causing issues and came very close to
   removing another, that one fixed the problems promptly.  I'm not sure
   if I'm actually being more pushy here (as was requested), that's
   about all the issues that came to my attention.

 - We now do allnoconfig builds on the incremental builds, this does
   occasionally catch things that are allnoconfig specific which I did
   get some reasonable grumbling about but I think the majority of
   issues are things that would show up with any other build so the
   failing fast is very useful.

 - Swapped around a bunch of the targets from PowerPC to arm64.

 - I live in Europe not Austraila which has messed with some people's
   schedules.

Things that I'm aware of that have been suggested but didn't happen, or
where I'm aware of issues:

 - Covering the documentation builds, I don't think I've ever seen them
   building cleanly when I've looked and IIRC there were some issues
   with not getting error codes on failure too.  I do intermittently
   build as part of the final build.

 - Standard reporting of duplicate commits (the tooling does notice, but
   it's a manual job to actually tell anyone about it which mostly only
   happens if I notice them causing a conflict).
 
 - Pushing out mails more promptly, there's a manual step where things
   get dropped into my postponed folder and I don't always actually send
   as fast as I should (the "tree for today" mails ending up getting
   sent the next day is the worst for this).

Any other ideas?

Thanks to Thierry and Breno for helping out with holiday cover.  There's
also a bunch of stuff changed with the scripting which they're also
helping with but isn't really visible if you're not actually running
-next.

[1] https://lore.kernel.org/r/20260805-rust-reverse-randstruct-dep-v3-1-7b8b2c761d6e@kernel.org

Thanks,
Mark

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

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

[Geert Uytterhoeven]

Hi Mark (et al),

On Tue, 11 Aug 2026 at 19:16, Mark Brown <broonie@kernel.org> wrote:
> I was reminded by some of the maintainers summit threads that it would
> be a good idea to check in about how things are going with -next and if
> anyone has any ideas for things that could be done better.  I've flagged
> this as a maintainers summit topic just in case but I think it's quite
> probably more of a list thing.
>
> Mostly it's been business as usual, hopefully I'll get better at doing
> merges as time goes on.  That said the list of visible changes I wrote
> seems a bit long:

[...[

>  - Started sending out a weekly summary of the state of the world -
>    perhaps there's extra stuff I could be adding in there?

Thanks, I wasn't aware of that!

>  - I live in Europe not Austraila which has messed with some people's
>    schedules.

If this is the only minus point I could come up with, then everything
must be working fine ;-)

Seriously, linux-next is working as well as ever before!
Thanks a lot!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

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

[Uwe Kleine-König]

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

Hello Mark,

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

So the resulting history doesn't look like:

*   4c0d3bb911f5 Merge branch 'E' into HEAD
|\
| * 43c281fce114 E
* |   13879e35a4ac Merge branch 'D' into HEAD
|\ \
| * | fc44516d50b1 D
| |/
* |   7264b63a7026 Merge branch 'C' into HEAD
|\ \
| * | 16f2802060cb C
| |/
* |   5928d0287cf0 Merge branch 'B' into HEAD
|\ \
| * | 793fdef4e4e3 B
| |/
|/
* 1e7199adfd77 base

but:

*   53dad0ca9b44 (HEAD) Merge branch 'B+C' into 'D+E'
|\
| *   54d327c589e7 Merge branch 'E' into 'D'
| |\
| | * 43c281fce114 E
| * | fc44516d50b1 D
| |/
* |   e75826f69561 Merge branch 'C' into 'B'
|\ \
| * | 16f2802060cb C
| |/
* / 793fdef4e4e3 B
|/
* 1e7199adfd77 base

.

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'm not convinced the advantages outweight the additional effort, but
IMHO this is a bit similar to the request by the filesystem guys to have
a tree with only filesystem changes.

So this is just an idea that might be worth to be thought about by more
than just me.

Best regards
Uwe


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

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

[Breno Leitao]

On Tue, Aug 11, 2026 at 05:54:59PM +0100, Mark Brown wrote:
> Any other ideas?

I'm new to this area, so please forgive what might be a silly
question: would it make sense for maintainers' -next trees to keep
a stable git history?

Some maintainer trees are already stable and append-only, which
gives linux-next users/testers stable commits to point to, instead
of ephemeral commits that can disappear later due to history
rewrites.

Would getting rid of these ephemeral commits make linux-next easier
to work with?

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

[Steven Rostedt]

On Wed, 12 Aug 2026 04:42:21 -0700
Breno Leitao <leitao@debian.org> wrote:

> On Tue, Aug 11, 2026 at 05:54:59PM +0100, Mark Brown wrote:
> > Any other ideas?  
> 
> I'm new to this area, so please forgive what might be a silly
> question: would it make sense for maintainers' -next trees to keep
> a stable git history?
> 
> Some maintainer trees are already stable and append-only, which
> gives linux-next users/testers stable commits to point to, instead
> of ephemeral commits that can disappear later due to history
> rewrites.
> 
> Would getting rid of these ephemeral commits make linux-next easier
> to work with?

This has come up at the Maintainers Summit in the past. I believe it is
even in the article I posted earlier in another thread.

   https://lwn.net/Articles/1050027/

We are even discussing issues about this in that other thread as well:

  https://lore.kernel.org/all/0a8c1e90-1de1-4a76-b0fa-e367a4bd4f55@sirena.org.uk/

I try to keep my linux-next branch clean, but I do rebase to add tags. I do
on occasion remove commits if they prove to be totally broken. That's rare
but I rather have that then having to push something to Linus where a bunch
of commits are simply reverted.

-- Steve

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

[Lee Jones]

On Wed, 12 Aug 2026, Steven Rostedt wrote:

> On Wed, 12 Aug 2026 04:42:21 -0700
> Breno Leitao <leitao@debian.org> wrote:
> 
> > On Tue, Aug 11, 2026 at 05:54:59PM +0100, Mark Brown wrote:
> > > Any other ideas?  
> > 
> > I'm new to this area, so please forgive what might be a silly
> > question: would it make sense for maintainers' -next trees to keep
> > a stable git history?
> > 
> > Some maintainer trees are already stable and append-only, which
> > gives linux-next users/testers stable commits to point to, instead
> > of ephemeral commits that can disappear later due to history
> > rewrites.
> > 
> > Would getting rid of these ephemeral commits make linux-next easier
> > to work with?
> 
> This has come up at the Maintainers Summit in the past. I believe it is
> even in the article I posted earlier in another thread.
> 
>    https://lwn.net/Articles/1050027/
> 
> We are even discussing issues about this in that other thread as well:
> 
>   https://lore.kernel.org/all/0a8c1e90-1de1-4a76-b0fa-e367a4bd4f55@sirena.org.uk/
> 
> I try to keep my linux-next branch clean, but I do rebase to add tags. I do
> on occasion remove commits if they prove to be totally broken. That's rare
> but I rather have that then having to push something to Linus where a bunch
> of commits are simply reverted.

+1

FWIW, I have always reserved the right to rebase in order to remove,
move around, reword and otherwise fix-up commits and do so often.  To
that end my 'next' branches are not, have ever been, nor do I intend
them to ever be, stable.

-- 
Lee Jones

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

[Mark Brown]

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

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'm not convinced the advantages outweight the additional effort, but
> IMHO this is a bit similar to the request by the filesystem guys to have
> a tree with only filesystem changes.

> So this is just an idea that might be worth to be thought about by more
> than just me.

Yeah, there was also Sasha was talking about something with trying to
make loosely topic based subtrees.  As you mention there's a scripting
and comprehensibility cost to doing something like this, both when
building the tree and when trying to understand the results.  If people
actually want the intermediate trees directly like with the filesystems
stuff then sure, but if there's no demand for the specific combinations
of trees I'm not sure it's worth it.

There's also the issue of incremental build benefits.

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

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

[Sasha Levin]

On Wed, Aug 12, 2026 at 05:37:30PM +0100, 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'm not convinced the advantages outweight the additional effort, but
>> IMHO this is a bit similar to the request by the filesystem guys to have
>> a tree with only filesystem changes.
>
>> So this is just an idea that might be worth to be thought about by more
>> than just me.
>
>Yeah, there was also Sasha was talking about something with trying to
>make loosely topic based subtrees.  As you mention there's a scripting
>and comprehensibility cost to doing something like this, both when
>building the tree and when trying to understand the results.  If people

Right. I have an experiment that I ran here:
https://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-next.git/ where I
scripted something that generates those *-next branches based on category tags
I've added to the manifest:
https://gist.github.com/sashalevin/15dbe4cfe2e2a3c4706788b07ef48079 .

>actually want the intermediate trees directly like with the filesystems
>stuff then sure, but if there's no demand for the specific combinations
>of trees I'm not sure it's worth it.
>
>There's also the issue of incremental build benefits.

Which is mostly the reason I kept silent on this thread :)

My original goal with that work was to evaluate AI merge conflict resolution
and measure it against the work that both the -next folks do as well as Linus.

I suppose that if folks are interested, this is something I can keep running
consistently, with the caveat that conflict resolutions are purely AI driven,
which could be enough for something we feed to CI and bots.

-- 
Thanks,
Sasha

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

[Mark Brown]

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

On Wed, Aug 12, 2026 at 12:45:15PM -0400, Sasha Levin wrote:
> On Wed, Aug 12, 2026 at 05:37:30PM +0100, Mark Brown wrote:

> > actually want the intermediate trees directly like with the filesystems
> > stuff then sure, but if there's no demand for the specific combinations
> > of trees I'm not sure it's worth it.

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

> Which is mostly the reason I kept silent on this thread :)

> My original goal with that work was to evaluate AI merge conflict resolution
> and measure it against the work that both the -next folks do as well as Linus.

> I suppose that if folks are interested, this is something I can keep running
> consistently, with the caveat that conflict resolutions are purely AI driven,
> which could be enough for something we feed to CI and bots.

Like I say if it's useful to people I'm not completely against the idea,
I'd just rather not pay the costs if nobody is going to benefit from it.

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

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

[Guenter Roeck]

On 8/12/26 08:59, Lee Jones wrote:
> On Wed, 12 Aug 2026, Steven Rostedt wrote:
> 
>> On Wed, 12 Aug 2026 04:42:21 -0700
>> Breno Leitao <leitao@debian.org> wrote:
>>
>>> On Tue, Aug 11, 2026 at 05:54:59PM +0100, Mark Brown wrote:
>>>> Any other ideas?
>>>
>>> I'm new to this area, so please forgive what might be a silly
>>> question: would it make sense for maintainers' -next trees to keep
>>> a stable git history?
>>>
>>> Some maintainer trees are already stable and append-only, which
>>> gives linux-next users/testers stable commits to point to, instead
>>> of ephemeral commits that can disappear later due to history
>>> rewrites.
>>>
>>> Would getting rid of these ephemeral commits make linux-next easier
>>> to work with?
>>
>> This has come up at the Maintainers Summit in the past. I believe it is
>> even in the article I posted earlier in another thread.
>>
>>     https://lwn.net/Articles/1050027/
>>
>> We are even discussing issues about this in that other thread as well:
>>
>>    https://lore.kernel.org/all/0a8c1e90-1de1-4a76-b0fa-e367a4bd4f55@sirena.org.uk/
>>
>> I try to keep my linux-next branch clean, but I do rebase to add tags. I do
>> on occasion remove commits if they prove to be totally broken. That's rare
>> but I rather have that then having to push something to Linus where a bunch
>> of commits are simply reverted.
> 
> +1
> 
> FWIW, I have always reserved the right to rebase in order to remove,
> move around, reword and otherwise fix-up commits and do so often.  To
> that end my 'next' branches are not, have ever been, nor do I intend
> them to ever be, stable.
> 
Same here.

Guenter

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

[Arnaldo Carvalho de Melo]

On Wed, Aug 12, 2026 at 10:10:17AM -0700, Guenter Roeck wrote:
> On 8/12/26 08:59, Lee Jones wrote:
> > On Wed, 12 Aug 2026, Steven Rostedt wrote:
> > > On Wed, 12 Aug 2026 04:42:21 -0700
> > > Breno Leitao <leitao@debian.org> wrote:
> > > > On Tue, Aug 11, 2026 at 05:54:59PM +0100, Mark Brown wrote:
> > > > Would getting rid of these ephemeral commits make linux-next easier
> > > > to work with?

> > > This has come up at the Maintainers Summit in the past. I believe it is
> > > even in the article I posted earlier in another thread.

> > >     https://lwn.net/Articles/1050027/

> > > We are even discussing issues about this in that other thread as well:

> > >    https://lore.kernel.org/all/0a8c1e90-1de1-4a76-b0fa-e367a4bd4f55@sirena.org.uk/

> > > I try to keep my linux-next branch clean, but I do rebase to add tags. I do
> > > on occasion remove commits if they prove to be totally broken. That's rare
> > > but I rather have that then having to push something to Linus where a bunch
> > > of commits are simply reverted.

> > +1

> > FWIW, I have always reserved the right to rebase in order to remove,
> > move around, reword and otherwise fix-up commits and do so often.  To
> > that end my 'next' branches are not, have ever been, nor do I intend
> > them to ever be, stable.

> Same here.

I do it as a last resort, but its better to avoid having bug+fix things
hitting upstream, i.e. trying to help with upstream bisectability.

- Arnaldo

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

[Guenter Roeck]

On 8/12/26 10:14, Arnaldo Carvalho de Melo wrote:
> On Wed, Aug 12, 2026 at 10:10:17AM -0700, Guenter Roeck wrote:
>> On 8/12/26 08:59, Lee Jones wrote:
>>> On Wed, 12 Aug 2026, Steven Rostedt wrote:
>>>> On Wed, 12 Aug 2026 04:42:21 -0700
>>>> Breno Leitao <leitao@debian.org> wrote:
>>>>> On Tue, Aug 11, 2026 at 05:54:59PM +0100, Mark Brown wrote:
>>>>> Would getting rid of these ephemeral commits make linux-next easier
>>>>> to work with?
> 
>>>> This has come up at the Maintainers Summit in the past. I believe it is
>>>> even in the article I posted earlier in another thread.
> 
>>>>      https://lwn.net/Articles/1050027/
> 
>>>> We are even discussing issues about this in that other thread as well:
> 
>>>>     https://lore.kernel.org/all/0a8c1e90-1de1-4a76-b0fa-e367a4bd4f55@sirena.org.uk/
> 
>>>> I try to keep my linux-next branch clean, but I do rebase to add tags. I do
>>>> on occasion remove commits if they prove to be totally broken. That's rare
>>>> but I rather have that then having to push something to Linus where a bunch
>>>> of commits are simply reverted.
> 
>>> +1
> 
>>> FWIW, I have always reserved the right to rebase in order to remove,
>>> move around, reword and otherwise fix-up commits and do so often.  To
>>> that end my 'next' branches are not, have ever been, nor do I intend
>>> them to ever be, stable.
> 
>> Same here.
> 
> I do it as a last resort, but its better to avoid having bug+fix things
> hitting upstream, i.e. trying to help with upstream bisectability.
> 

That, but mostly adding tags.

Guenter

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

[Arnaldo Carvalho de Melo]

On Wed, Aug 12, 2026 at 10:37:34AM -0700, Guenter Roeck wrote:
> On 8/12/26 10:14, Arnaldo Carvalho de Melo wrote:
> > On Wed, Aug 12, 2026 at 10:10:17AM -0700, Guenter Roeck wrote:
> > > On 8/12/26 08:59, Lee Jones wrote:
> > > > On Wed, 12 Aug 2026, Steven Rostedt wrote:
> > > > > On Wed, 12 Aug 2026 04:42:21 -0700
> > > > > Breno Leitao <leitao@debian.org> wrote:
> > > > > > On Tue, Aug 11, 2026 at 05:54:59PM +0100, Mark Brown wrote:
> > > > > > Would getting rid of these ephemeral commits make linux-next easier
> > > > > > to work with?
> > 
> > > > > This has come up at the Maintainers Summit in the past. I believe it is
> > > > > even in the article I posted earlier in another thread.
> > 
> > > > >      https://lwn.net/Articles/1050027/
> > 
> > > > > We are even discussing issues about this in that other thread as well:
> > 
> > > > >     https://lore.kernel.org/all/0a8c1e90-1de1-4a76-b0fa-e367a4bd4f55@sirena.org.uk/
> > 
> > > > > I try to keep my linux-next branch clean, but I do rebase to add tags. I do
> > > > > on occasion remove commits if they prove to be totally broken. That's rare
> > > > > but I rather have that then having to push something to Linus where a bunch
> > > > > of commits are simply reverted.
> > 
> > > > +1
> > 
> > > > FWIW, I have always reserved the right to rebase in order to remove,
> > > > move around, reword and otherwise fix-up commits and do so often.  To
> > > > that end my 'next' branches are not, have ever been, nor do I intend
> > > > them to ever be, stable.

> > > Same here.

> > I do it as a last resort, but its better to avoid having bug+fix things
> > hitting upstream, i.e. trying to help with upstream bisectability.
> 
> That, but mostly adding tags.

I do add committer notes while merging patches, that I don't do using
git merge (shame on me), but then downstreamers don't hand me git repos
to pull from.

But in my case since documentation on how to use new features is
difficult to get and I don't want to make that a requirement (shame on
me), I end up testing the new feature with a before and after, recording
precise set of instructions on how to use it so that at least I can go
back and check how to test that feature if something looks wrong
aftwerwards.

- Arnaldo

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

[Geert Uytterhoeven]

Hi Mark,

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.

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 -- geert@linux-m68k.org

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

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

[Uwe Kleine-König]

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

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

[Thierry Reding]

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

On Wed, Aug 12, 2026 at 04:42:21AM -0700, Breno Leitao wrote:
> On Tue, Aug 11, 2026 at 05:54:59PM +0100, Mark Brown wrote:
> > Any other ideas?
> 
> I'm new to this area, so please forgive what might be a silly
> question: would it make sense for maintainers' -next trees to keep
> a stable git history?
> 
> Some maintainer trees are already stable and append-only, which
> gives linux-next users/testers stable commits to point to, instead
> of ephemeral commits that can disappear later due to history
> rewrites.
> 
> Would getting rid of these ephemeral commits make linux-next easier
> to work with?

I think this is a problem that we can easily address using tools. next
already has scripts to detect these issues and I think perhaps we can
provide a variant of those in a way that would allow people to set them
up in their tree as maybe git hooks so they automatically get run on
pre-push or something.

On the trees that I maintain, I do that using a set of scripts that I've
found useful. I know many other maintainers do their own versions of the
same tests and I suspect the maintainers that don't are in the category
of not knowing that they should be checking for these thing or just
don't know how or lack the time/motivation to set this up. If we can
take some of the lessons learned from linux-next and distill it into
some scripts and maybe documentation, I think we can catch the vast
majority of these cases, and the rest we can catch in linux-next, or we
can ask Linus to run this set of sanity checks on merges as a last
resort.

Thierry

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

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

[Mark Brown]

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

On Thu, Aug 13, 2026 at 11:59:19AM +0200, Thierry Reding wrote:
> On Wed, Aug 12, 2026 at 04:42:21AM -0700, Breno Leitao wrote:

> > Would getting rid of these ephemeral commits make linux-next easier
> > to work with?

> I think this is a problem that we can easily address using tools. next
> already has scripts to detect these issues and I think perhaps we can
> provide a variant of those in a way that would allow people to set them
> up in their tree as maybe git hooks so they automatically get run on
> pre-push or something.

Krzysztof Kozlowski did a bunch of scripts/hooks that the soc tree
people use, that's probably an easy thing for people to integrate,
though since I don't have the URL to hand I guess it needs more
publicity.

> On the trees that I maintain, I do that using a set of scripts that I've
> found useful. I know many other maintainers do their own versions of the
> same tests and I suspect the maintainers that don't are in the category
> of not knowing that they should be checking for these thing or just
> don't know how or lack the time/motivation to set this up. If we can
> take some of the lessons learned from linux-next and distill it into
> some scripts and maybe documentation, I think we can catch the vast
> majority of these cases, and the rest we can catch in linux-next, or we
> can ask Linus to run this set of sanity checks on merges as a last
> resort.

TBH given the volume of commits the error rate is very low.

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

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

[Krzysztof Kozlowski]

On 13/08/2026 13:25, Mark Brown wrote:
> On Thu, Aug 13, 2026 at 11:59:19AM +0200, Thierry Reding wrote:
>> On Wed, Aug 12, 2026 at 04:42:21AM -0700, Breno Leitao wrote:
> 
>>> Would getting rid of these ephemeral commits make linux-next easier
>>> to work with?
> 
>> I think this is a problem that we can easily address using tools. next
>> already has scripts to detect these issues and I think perhaps we can
>> provide a variant of those in a way that would allow people to set them
>> up in their tree as maybe git hooks so they automatically get run on
>> pre-push or something.
> 
> Krzysztof Kozlowski did a bunch of scripts/hooks that the soc tree
> people use, that's probably an easy thing for people to integrate,
> though since I don't have the URL to hand I guess it needs more
> publicity.

Here's the most recent variant of the toolset I collected from Greg and
Steven + a few new (like to avoid back-merging b4 branches which did
happen in the past... remember the day b4 was non-working for every
contributor using mainline kernel?):
https://web.git.kernel.org//pub/scm/linux/kernel/git/soc/soc-tools.git


The hooks are trivial to setup, I even added install.sh, so honestly
having incorrect "Fixes" tags or missing SoB by the maintainer cannot be
excused really.

I was describing them in my speech about maintainer's toolbox 3 years ago:
https://lpc.events/event/17/contributions/1498/


Best regards,
Krzysztof

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

[Mark Brown]

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

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:

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

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