Re: [RFC 0/5] LLMinus: LLM-Assisted Merge Conflict Resolution

Mark Brown
2026-01-05T18:30:23Z

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

On Mon, Jan 05, 2026 at 01:00:20PM -0500, Sasha Levin wrote:
> On Tue, Dec 23, 2025 at 05:47:58PM +0000, Mark Brown wrote:

> > To be clear unless things are super prone to conflicts the big cost with
> > adding stuff to -next isn't generally doing the merges, it's build
> > testing the results. To that end the main potential advantage I can see
> > in doing submerges would be if we could parallelise the build testing
> > portion of things. That would need some consideration of the complexity
> > of the scripting, the build machines and the cogantive load involved,
> > and if we were doing that the considerations for constructing submerges
> > would be a bit different. It has crossed my mind, but it'd be non
> > trivial to do and not intending to produce intermediate merges that are
> > useful to anyone else.

> The way I have it working is that I will only recreate a sub-tree if any of the
> -next trees that are part of it were rebased, otherwise I will just merge new
> changes on top of the existing tree.

> I will also do a build test only after I merged everything into the sub-tree.
> If we hit a build error, I will bisect between the last known good point and
> HEAD.

Yeah, there's already optimisations along those lines in there which
help a lot.

> Between the above, as well as tracking "known-broken" trees, the volume of
> build tests is not that scary.

Most of the time it's fine like you say, otherwise it'd be completely
unsustainable. Some of the time between the number of trees that decide
to simultaneously make changes that trigger full allmodconfig rebuilds,
generate messy conflicts or whatever else things blow up in your face.
There's an interlock in the scripts that stops releases going out after
3am or something which I am pretty confident is in there due to bitter
experience.

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