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

[Sasha Levin <sashal@kernel.org>]

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