U-Boot Concept Tree Proposal

[Simon Glass]

Hi Quentin,

On Mon, 6 Jul 2026 at 10:29, Quentin Schulz <quentin.schulz at cherry.de> wrote:
>
> 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").

Right, we don't want them on the ML (tried that!)

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

I suppose it depends how long from tree to master or next. Maintainers
tend to have have code that sits around and isn't sent for a while.
But it is normally in individual branches rather than all piled up
into one big list of commits.

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

OK well perhaps it isn't that important. The fact that it keeps up
with mainline is why I don't think of it as a fork. But no matter.

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

I'm sorry about that. Let's just say there was frustration on both sides.

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

I hope not.

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

Yes, that's true, and in fact I cannot point to the website properly
at the moment as it refuses to load at u-boot.org

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

This was not the original driver of the Concept tree. AI is perhaps
something we could discuss on one of the calls, once the infra stuff
is finished.

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

Exactly.

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

It is providing an option which currently does not exist, but I think
needs to exist. If you go back 10 years to when EFI was added to
U-Boot, no one asked whether it was perfect, or complete, or fully
migrated, etc. It was years before the EFI loader could actually boot
properly (I recall even in 2022 hacking away to get it to boot Ubuntu
on a Chromebook). But now we want to have things that work perfectly
and are complete, or we won't take the series. We need a way to build
up features such that they can be proven and then brought into
mainline.

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

I do a reasonable job of this for the smaller things. But for the
larger things, particularly boot-related, particularly multi-series
efforts, I tend to run out of steam. Wouldn't anyone? WIth Concept
I've been able to finish things, such as the PXE refactor, expo and
the EFI apps, that I would struggle to do in mainline doing a series
of <15 patches 4 times a year.

I know we already discussed this topic in a call some weeks back and
Michal had an idea for a staging area. Should we try to get interested
people to attend the next call and try to figure out a path forward?

Regards,
Simon