U-Boot Concept Tree Proposal

[Simon Glass]

Hi Peter,

On Fri, 3 Jul 2026 at 11:11, Peter Robinson <pbrobinson at gmail.com> wrote:
>
> Hi Simon,
>
> > > >>>>> 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.
> > > >
> >
> > Thanks for taking the time to reply to this - it is a very important
> > but very quiet thread.
> >
> > >
> > > 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.
> >
> > U-Boot tends to follow Linux, so we'll see what U-Boot's policy turns
> > out to be in .rst format. I am hopeful that eventually more people
> > will see the cost/benefit ratio of AI in a different light. My
> > understanding is the policy will be addressed once the infra move is
> > finished. Linux requires disclosure, something I have worked hard to
> > do in Concept. The legal question is covered by Linux's policy too
> > [1]. I do understand that any new technology creates fans and
> > opponents, problems and opportunities. Some thoughts at [3]
> >
> > My approach has generally been to embrace change (and deal with the
> > fallout) rather than to resist it.
> >
> > >
> > > 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.
> >
> > I don't want to speak for Tom, but yes I can trace the genesis of
> > Concept to the increasing difficultly of getting things accepted,
> > particularly large things like bootstd and VBE. What do you suggest
> > instead of Concept?
> >
> > >
> > > You keep repeating Concept is not a fork, but I don't understand how it
> > > can NOT be one.
> >
> > Concept cherry-picks from mainline so that it stays up-to-date. So it
> > should be possible to grab a feature from Concept and apply it to
> > mainline without too many conflicts. A fork does not care about
> > mainline at all. This is a big and complex topic though, since
> > features build on each other (e.g. see the BLS thread [2] where the
> > Concept version builds on pxe_utils refactoring, making it hard to get
> > into mainline without several precursor series).
>
> A fork of a project is where it diverges which a number of different
> features, there's lots of projects with forks where the forks cherry
> pick between each other and try and remain largely compatible. One
> example that comes to mind is Linux Foundation forked the Ubuntu LXD
> project to a project called Incus.
>
> > > 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.
> >
> > Yes it could be confusing...I'm open to ideas on how to handle that.
> >
> > > 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).
> >
> > See above re fork. I am responsible for the articles, although Claude
> > and Gemini helped write most of them. I thought I was being quite
> > careful to label things as 'Concept', but I've just gone back through
> > and found a good number unfortunately did not. I've fixed those and
> > also updated the titles in about 20 cases too. Please let me know if
> > you see other problems.
> >
> > > 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.
> >
> > OK. Would a URL link to Concept be acceptable?
>
> I don't think we have buy in from the community into the whole concept
> fork as it is to be actually discussing links as yet.
>
> I think you need to answer the questions to the community about concept:
> 1) Why are you holding the u-boot.org domain hostage over this
> 2) Maybe you need to read back through the input from the community
> and revist what you think concept should be
>
> I feel I was very clear, both on the community call when it was bought
> up, which lead to you starting this thread so I had assumed you
> understood that you had to get the community buy in.
>
> In the follow up private discussions about it after it was clear as a
> whole that the PLC was uncomfortable with a specific websiite (we
> don't plan on supporting forks, would we provide that feature for all
> forks?) for concept. I offered the idea of a custodians tree to allow
> you to develop and maintain the features that you were preparing for
> upstream in your concept tree to enable easier collaboration for those
> that wished to work with you on those specific features. Maybe I
> wasn't clear enough in my communications but it was never intended to
> be the location to host a fork.

A fork would be something which forks off mainline and goes its
separate way. Concept is not a fork. Perhaps a constantly merged,
multi-feature branch would be a better term. Please read my original
email again on this point and I'm happy to explain it further. Quite a
few series have already found their way to mainline.

> So I think you need to revist what the idea of concept actually is and
> come back to the community with an adjusted proposal.

It seems that you are rejecting the whole idea of a Concept tree (my
original post on this thread). Can you please confirm that? But if you
have ideas on how it could work with modifications, please share them.
There must be some common ground somewhere.

>
> First though, I repeat again, would you please explain to the
> community why you are holding the u-boot.oirg domain hostage to try
> and force the PLC to accept an idea that we have been explicit about
> the need to get the community to buy into this "concept". I think the
> community deserves an answer.

This is a bit of a one-sided view. The real situation is that for many
years to implement major features and improvements in U-Boot, but that
became progressively more difficult as Tom started refusing to accept
series and I have no ability to get PRs applied. Perhaps I was naive
to expect our good working relationship would continue forever, but I
have contributed a huge amount to U-Boot and having the rug pulled out
felt very unfair, not to say bad for the project. Regarding the
domain, I have offered to point subdomains to anywhere you wish, which
would resolve this. In the meantime I have mirrored the website and
moved various things away from the domain. But I cannot support the
sort of split that happened with Barebox, if that is your goal.

I don't mind hosting a separate tree somewhere else, if that is your
preference, but it needs to have some relationship with U-Boot and a
clear understanding of what that relationship is. If that is not
possible / acceptable, then I suppose we should close this thread. I'm
skeptical of our ability to resolve complex things on mailing lists in
cany case, although I started this thread at your request.

>
> > > 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.
> >
> > Yes I have generally been the most active reviewer over the last 10
> > years or so, although sometimes I have burnout and stop.
> >
> > Here's how people become reviewers, IMO:
> >
> > Step 1: Punter has a problem, debugs it and conceives a fix / feature
> > to resolve it
> > Step 2: Punter sends a patch or short series
>
> I'm not sure it's appropriate to call our developers and contributors
> "Punters" [1] please be respectful of people.

It's a pretty common term in the UK, at least, certainly not
disrespectful from my understanding or intention, using it to mean a
customer willing to buy or try out the product. I wasn't aware of the
urban definitions and now I wish I hadn't just read them!

>
> > Step 3a: People review the code and Tom accepts some version of it
> > Step 3b: Patch is rejected, or people are mean or dismissive, or don't
> > understand the problem, or the effort gets too great (punter exits
> > here and goes to write his own firmware in Rust :-)
> > Step 5: Punter sees a related patch from someone else and decides to
> > reply with some thoughts
> > Step 6: Punter starts getting interested in more areas of U-Boot,
> > sending patches and reviewing, etc.
>
> I think going from a single patch to a firmware written in rust is a
> bit of a fanciful stretch.
>
> From experience people involved in the project review things when:
> 1) They know the topic or the hardware
> 2) Are interested in the features or functionality provided
> 3) Are a maintainer of a device or subsystem
> 4) Wish to assist
> 5) they have hardware they can test on
> 6) they wish to scratch an iitch.

That's fine, we have a somewhat different experience. From my years of
watching this, it mostly starts with people seeing their code accepted
(motivated by your #6).

Regards,
Simon

>
> [1] https://www.urbandictionary.com/define.php?term=punter