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