U-Boot Concept Tree Proposal

[Quentin Schulz]

Hi Simon,

On 7/4/26 6:30 PM, Simon Glass wrote:
> Hi Peter,
> 
> On Fri, 3 Jul 2026 at 11:11, Peter Robinson <pbrobinson at gmail.com> wrote:
[...]
>>
>> 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,

But... patches in Concept have already gone their separate way? We don't 
have them on the ML (nor do we want them at the moment as they are 
mostly AI-written and the Tom's position on the topic is currently "don't").

> 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.
> 

If it's not mainline or a maintainer tree with commits on their way to 
master or next, it's a fork to me. FWIW, I think we could even consider 
the maintainer tree as a fork as well, but since it's explicitly listed 
as our workflow (c.f. 
https://docs.u-boot-project.org/en/latest/develop/process.html#work-flow-of-a-custodian) 
then I guess it's not one (not in the strict term).

My company has a U-Boot tree + a few patches that are mainline, I don't 
claim it's NOT a fork even though all commits are either already merged 
or already sent to the mailing list (a requirement we have for anything 
upstream: send first to the ML, then we import if from the ML). In that 
regard, Concept would be worse as there's no guarantee patches in 
Concept would even make it to the mailing list.

Your insistence that Concept is not a fork is puzzling to be honest.

>> 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.
> 

I'll let Peter speak his mind.

As for myself, I don't care about anything not going to the ML. I 
wouldn't want an ostensible fork be hosted on official infra.

You've made multiple reviews in the past on the ML mentioning Concept to 
users (I know, I received one and had to look up what this thing was). 
You continued to merge other people's patches in your maintainer tree 
while Tom had refused to take some of your pull requests and continued 
to reply to patches on the ML that they were merged, even though they 
were blocked by other patches in the same pull request Tom had refused 
to take. You repeatedly failed (back then) to take into account Tom's 
request to stop bombarding the ML with long and difficult to review 
patch series. The situation ended up with you being on hiatus for 6 
months. You can imagine I'm being a bit skeptical what your actual 
intent is with hosting Concept on official infra and claiming it is not 
a fork.

There may not necessarily be a common ground or compromise, rejection 
may be what the project decides.

>>
>> 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.
> 

You didn't answer Peter's question. Also note that you're not doing the 
redirect properly, c.f. https://docs.u-boot.org/en/latest/ (and I'm 
assuming all URLs except the base one). If we don't own the domain, we 
cannot make use of it as a third party (you) will be free to serve 
whatever they want would they change their mind in the future (and we 
wouldn't necessarily know). I do not want to be included in this 
discussion but "hand over the domain" != "i can redirect for you".

Pasting the rest of the discussion in the other thread here as Peter has 
started referencing it so maybe we can merge the discussion into one 
(copy-pasting manually so maybe I'll mangle the "depth" of answers). 
EDIT: well, took too long and Peter answered already, but eh, here it is 
anyway.

 >>
 >> 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]
 >

Note that SFC (under whose umbrella U-Boot now is) != LF and the 
official stance of SFC is now available at: 
https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html

I will quote some part in the preamble that I think is worth highlighting:

"""
Some FOSS project leaders have taken a zero-tolerance approach to any 
LLM-gen-AI contributions to their projects. We support leaders who make 
such decisions.
"""

So it's possible the project decides we don't want to go ahead with 
encouraging the use of LLM/AI. At the same time, we import a 
non-negligible amount of code from the Linux kernel which for some 
subsystems allow LLM/AI tools, so the project is already tainted by 
AI/LLM (or soon, e.g. via dts/upstream in v7.1).

 > My approach has generally been to embrace change (and deal with the
 > fallout) rather than to resist it.

Note that *you* may decide *you* want to embrace change, but it doesn't 
necessarily mean the project wants to accept it/them.

 >> 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?

I understand. But I fail to see how you're addressing the issue with 
Concept? Like, how is this going to help you get things merged into 
mainline? Being cynical here but the only positive outcome I see for you 
with Concept is strong-arming the project into accepting your changes 
that we're currently rejecting/not reviewing.

The difficulty of contributing to open-source projects is not new: you 
must have buy-in from other people to get interest from reviewers and 
maintainers to get your code merged. Convince people your thing is the 
right thing, justify your patches, provide ample context in cover 
letters and patches so drive-by reviewers or people with little time 
have it easier to review your code, contact distros to figure out if 
they are behind your project (e.g. VBE) and get their support and public 
push otherwise this is someone having a grand plan for how things should 
be but they forget other people are involved for this grand plan to work 
or even be used.

Quentin