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