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

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

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

[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