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
