U-Boot Concept Tree Proposal

[Quentin Schulz]

Hi Simon,

On 6/18/26 5:06 PM, Simon Glass wrote:
[...]
>>>>> Another difference is AI. I believe that AI is the next step on from
>>>>> compilers, which also took a long time to produce good code and find
>>>>> acceptance. The Concept tree welcomes (and encourages) high-quality AI
>>>>> contributions and reviews. It accepts PRs and allows reviews on PRs or the
>>>>> mailing list. It relies 99% on automated tests (sandbox, QEMU and labs) so
>>>>> sets a high bar for testing. It uses a separate Gitlab instance for now and
>>>>> of course uses a separate mailing list and Patchwork project to avoid
>>>>> cluttering the main list. Concept runs an AI-powered cherry-picker so that
>>>>> it keeps up with mainline. In no sense is it operated as a fork.
>>>>
>>>> I'm clearly against using AI for any of development or review work as it
>>>> can't be fully trusted and will monopolize precious reviewers time reviewing
>>>> AI code instead of reviewing legitimate contributions from individual and companies.
>>>>
>>>> Using AI for CI testing and regression testing could help if it doesn't add
>>>> a burden for maintainers by reporting false positives.
>>>
>>> RIght, Tom has been very clear about this too, even suggesting that AI
>>> is actually unethical. This is indeed one of my motivations for the
>>> Concept tree.
>>
>> To avoid the scrutiny of using AI? If that's the case and you're
>> intention I have further concerns.
> 
> Not really the scrutiny...the more scrutiny the better, I think. But
> if mainline is anti-AI then Concept can provide a place where people
> can make use of it.
> 

Tom has clearly communicated multiple times that AI is generally not 
welcome in U-Boot. So how is accepting AI contributions into Concept 
compatible with "Once features are landed and functional in Concept I 
hope that many will find their way to mainline"? Who's going to do the 
work? Who's going to take the legal liability of reworking AI-written 
code for submission to mainline? How is this going to address the main 
issue you're having of "code is not landing"? It's still not in mainline.

What I think will happen is "I cannot get this merged into mainline so 
I'm going to get it merged into Concept and then direct my users at 
that". And eventually, over time, everything from this Concept 
contributor and their users will only land in Concept and we won't even 
have it on mainline ML.

You keep repeating Concept is not a fork, but I don't understand how it 
can NOT be one.

Considering Concept is apparently going to be hosted on the same GitLab 
instance as mainline, I see this as potentially confusing people as to 
what it actually is. I still am pretty upset at the various articles you 
or AI in your behalf posted on the u-boot.org website claiming support 
for various features in U-Boot either "submitted" (nowhere to be seen on 
the ML) or not explicitly stating they are merged in a fork of U-Boot 
(Concept, that is). That with the fact our official documentation used 
to be on docs.u-boot.org really made it look like (to me) we were behind 
this effort. We made the mistake of hosting the docs on a domain name we 
didn't (still don't?) control, I would like to avoid repeating the same 
mistake a different way by hosting a fork on the same instance as mainline.

U-Boot has friction also because we don't have enough reviewers or 
maintainers compared to the number of contributors. I don't see how you 
plan on addressing that by maintaining Concept by yourself (with an AI 
I'm assuming).
I appreciate you're possibly one of the most if not the most active 
reviewer on the ML and that there's not much more you can do to improve 
the situation aside from recruiting more people to review.

I also see "It relies 99% on automated tests (sandbox, QEMU and labs) so 
sets a high bar for testing." as wishful thinking. I'm sure you've read 
like most of us that it's not unusual for LLMs to write useless tests or 
tests that don't do anything, or even remove existing tests that don't 
pass because the instructions was all tests need to pass. We also 
already have tests and yet we still have plenty of bugs that weren't caught.

I'll finish that my gut feeling (shared with some of my current and 
former colleagues) is that U-Boot is disappointingly unstable. Unlike 
the Linux kernel, U-Boot suffers from fewer eyes looking at code, fewer 
people developing it, fewer people testing master or even any recent 
release (the number of reports we have for bugs on releases from years 
ago...), and lack of proper and extensive CI test infrastructure (and if 
we have some, it's heavily centralized into a handful of people's 
offices). I loathe every time I need to update U-Boot because I don't 
know what I'll have to debug for days or if I really do test everything 
there's to test (is it my fault for not keeping up with master, yes, but 
I shouldn't feel this way).
So I really think we could have much more confidence in code being 
merged if we had more testing, possibly on real hardware, possibly by 
companies offering to do some proper CI (e.g. like Intel is doing with 
Yocto, spending days testing release candidates before the project tags 
a release). Maybe with distros slowly adopting Aarch64 and U-Boot with 
it we'll have more coverage. I know you've worked on labgrid support for 
U-Boot and you have some merge request(s) still open there but it seems 
you're hitting the same wall there you're hitting here.

I think one of the issues could also be because you landed so many big 
features and reworks in the past, you're likely the only one who knows 
how things work in many parts of the project. binman comes to mind, 
bootflow/bootmeth, (signed) FIT, etc... Getting people to review your 
code is then difficult because it requires an enormous amount of effort 
to get into it and most people don't have that amount of time available 
to them (or willingness to spend it in that).

I believe we should be focusing on getting more reviewers, on many 
different parts of the code, and more automated testing, on real 
hardware. I believe that once we have this, then we will naturally have 
less time between submission and merge, and eventually can land bigger 
reworks or new features.

Cheers,
Quentin