U-Boot Concept Tree Proposal

U-Boot Concept Tree Proposal

[Simon Glass]

Dear U-Boot Contributors,

I would like to introduce the U-Boot Concept tree along with a few thoughts
on its role in U-Boot.

By way of background, I have been a contributor for about 15 years - around
10k commits and countless reviews. I have introduced many innovations into
the project: e.g. sandbox, device tree, C test infrastructure, Binman,
standard boot. Of course I could not have done any of this without the
U-Boot community (nor would there be any point).

As the U-Boot project has matured, the demands for mainline stability and
rigorous review have created a natural friction for landing complex,
large-scale feature and refactoring series at the necessary pace. This
structural reality, which has slowed the adoption of ambitious efforts like
bootstd, VBE, xPL [1], and CI-connected hardware labs, is what the Concept
tree is designed to alleviate.

I strongly believe that projects must evolve in order to stay relevant in
the long term. This includes code-refactoring, new features and subsystems,
along with migration of old code to use them.  A look back at the U-Boot of
2010 shows how far the project has come. I don't think anyone would still
be using U-Boot if it had not evolved.

I have set up a 'Concept' tree, a possible future for U-Boot, as a way to
regain the old pace of innovation. This environment is a proving ground for
new features where we maintain a lower bar for risk tolerance and
completeness. We will accept partial and speculative features, provided the
underlying code remains robust and of high quality, with the shared
understanding that features may be dropped if they do not prove beneficial.

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.

Once features are landed and functional in Concept I hope that many will
find their way to mainline, although inevitably some rework will be needed.

I recognise that introducing a new 'Concept' tree might initially cause
confusion or concern. This is an invitation to work together to define its
role. I welcome all feedback - positive or negative - here on the mailing
list, privately, or on irc. Let’s discuss how this initiative can help
U-Boot remain the defining firmware for the 2030s.

[1]
https://lore.kernel.org/u-boot/CAFLszTg6sKpZ1yP3Pjgk9_Fx3MOh=ieT2oaHfgLf3_nC+xXA9g@mail.gmail.com/

Concept tree:
                       :
                       ::
                     ...:::.
                 ::  :. -
           .   ::::::-  - ::. ..
          .:: .:      -==  =.:.
        ::.- ::::. ::. :=:. ::::
  ::. ::   =..  :.-::: =:
    .:-:-. -.::  ::=-:=:
  ::::::=.  -.::   ===:       ::.
    ::.:::=::=:   -===:--==-::--::
      :.    :-=-.:==:.   .:  ::
               ===:       ::  :
               ==:
               ==
              :==
              -==:
              -+=:
              =++=.
             .-===:

Re: U-Boot Concept Tree Proposal

[Ilias Apalodimas]

On Wed Jun 3, 2026 at 8:06 AM EEST, Simon Glass wrote:
> Dear U-Boot Contributors,

Hi Simon

>
> I would like to introduce the U-Boot Concept tree along with a few thoughts
> on its role in U-Boot.
>
> By way of background, I have been a contributor for about 15 years - around
> 10k commits and countless reviews. I have introduced many innovations into
> the project: e.g. sandbox, device tree, C test infrastructure, Binman,
> standard boot. Of course I could not have done any of this without the
> U-Boot community (nor would there be any point).
>
> As the U-Boot project has matured, the demands for mainline stability and
> rigorous review have created a natural friction for landing complex,
> large-scale feature and refactoring series at the necessary pace. This
> structural reality, which has slowed the adoption of ambitious efforts like
> bootstd, VBE, xPL [1], and CI-connected hardware labs, is what the Concept
> tree is designed to alleviate.
>

Well the problem here -- at least from my side, is that a lot of these features
are useful but feel half baked. E.g we found bugs in the bootstd uefi method and
those were not corner cases bugs. We couldn't even boot boards with it until [0].

I also think to an extent that's expected. Introducing big features will carry bugs
etc and that's fine. What's not fine is trying to merge all of them in a short
period of time. We need to find a working model, where new features are tested,
at least on a number of boards and become the default. Those changes also need
to be sent incrementally and be reviewable. You can't send a 50 patch series and
expect them to get merged in a week. You need to find a way to send smaller patches
that people can reliably review and accept.
FWIW there's similar code all over the place in the driver model.

The pattern here is that you add some code for an idea, but you spend little
effort plugging it in to the rest of the ecosystem and boards. You just magically
expect people to follow that and then you personally treat it as a U-Boot standard.

> I strongly believe that projects must evolve in order to stay relevant in
> the long term. This includes code-refactoring, new features and subsystems,
> along with migration of old code to use them.  A look back at the U-Boot of
> 2010 shows how far the project has come. I don't think anyone would still
> be using U-Boot if it had not evolved.

Agree

>
> I have set up a 'Concept' tree, a possible future for U-Boot, as a way to
> regain the old pace of innovation. This environment is a proving ground for
> new features where we maintain a lower bar for risk tolerance and
> completeness. We will accept partial and speculative features, provided the
> underlying code remains robust and of high quality, with the shared
> understanding that features may be dropped if they do not prove beneficial.
>
> 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.

Do you plan to merge patches that were written and reviewed only by AI agents?

> 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.
>
> Once features are landed and functional in Concept I hope that many will
> find their way to mainline, although inevitably some rework will be needed.
>
> I recognise that introducing a new 'Concept' tree might initially cause
> confusion or concern. This is an invitation to work together to define its
> role. I welcome all feedback - positive or negative - here on the mailing
> list, privately, or on irc. Let’s discuss how this initiative can help
> U-Boot remain the defining firmware for the 2030s.
>
> [1]
> https://lore.kernel.org/u-boot/CAFLszTg6sKpZ1yP3Pjgk9_Fx3MOh=ieT2oaHfgLf3_nC+xXA9g@mail.gmail.com/
>

[0] commit 4b151562bb8e541 ("bootmeth: pass size to efi_binary_run()")

Thanks
/Ilias

> Concept tree:
>                        :
>                        ::
>                      ...:::.
>                  ::  :. -
>            .   ::::::-  - ::. ..
>           .:: .:      -==  =.:.
>         ::.- ::::. ::. :=:. ::::
>   ::. ::   =..  :.-::: =:
>     .:-:-. -.::  ::=-:=:
>   ::::::=.  -.::   ===:       ::.
>     ::.:::=::=:   -===:--==-::--::
>       :.    :-=-.:==:.   .:  ::
>                ===:       ::  :
>                ==:
>                ==
>               :==
>               -==:
>               -+=:
>               =++=.
>              .-===:

Re: U-Boot Concept Tree Proposal

[Neil Armstrong]

Hi Simon,

On 6/3/26 07:06, Simon Glass wrote:
> Dear U-Boot Contributors,
> 
> I would like to introduce the U-Boot Concept tree along with a few thoughts
> on its role in U-Boot.
> 
> By way of background, I have been a contributor for about 15 years - around
> 10k commits and countless reviews. I have introduced many innovations into
> the project: e.g. sandbox, device tree, C test infrastructure, Binman,
> standard boot. Of course I could not have done any of this without the
> U-Boot community (nor would there be any point).
> 
> As the U-Boot project has matured, the demands for mainline stability and
> rigorous review have created a natural friction for landing complex,
> large-scale feature and refactoring series at the necessary pace. This
> structural reality, which has slowed the adoption of ambitious efforts like
> bootstd, VBE, xPL [1], and CI-connected hardware labs, is what the Concept
> tree is designed to alleviate.

The main issue to land complex large-scale feature and refactoring series is
mainly the lack of human highly qualified reviewers, proper shared project
infrastructure and funding for paid work. Not developers.

> 
> I strongly believe that projects must evolve in order to stay relevant in
> the long term. This includes code-refactoring, new features and subsystems,
> along with migration of old code to use them.  A look back at the U-Boot of
> 2010 shows how far the project has come. I don't think anyone would still
> be using U-Boot if it had not evolved.
> 
> I have set up a 'Concept' tree, a possible future for U-Boot, as a way to
> regain the old pace of innovation. This environment is a proving ground for
> new features where we maintain a lower bar for risk tolerance and
> completeness. We will accept partial and speculative features, provided the
> underlying code remains robust and of high quality, with the shared
> understanding that features may be dropped if they do not prove beneficial.

I'm clearly against having a separate official "U-Boot" fork tree, this will
only lead to confusion to users and contributors if it shares the same
mailing-list and name.

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

> 
> Once features are landed and functional in Concept I hope that many will
> find their way to mainline, although inevitably some rework will be needed.

Still I don't understand your point, Linux or Zephyr can land very complex
features with a single tree, what make U-Boot different here ?

> 
> I recognise that introducing a new 'Concept' tree might initially cause
> confusion or concern. This is an invitation to work together to define its
> role. I welcome all feedback - positive or negative - here on the mailing
> list, privately, or on irc. Let’s discuss how this initiative can help
> U-Boot remain the defining firmware for the 2030s.

Our immediate priority is helping U-Boot establish the proper technical and
legal infrastructure to receive funding. Adding AI features, maintaining
separate forks, and managing competing domains only distracts us from the
critical task of switching off the dying Denx infrastructure.

This is my personal opinion,
Neil

> 
> [1]
> https://lore.kernel.org/u-boot/CAFLszTg6sKpZ1yP3Pjgk9_Fx3MOh=ieT2oaHfgLf3_nC+xXA9g@mail.gmail.com/
> 
> Concept tree:
>                         :
>                         ::
>                       ...:::.
>                   ::  :. -
>             .   ::::::-  - ::. ..
>            .:: .:      -==  =.:.
>          ::.- ::::. ::. :=:. ::::
>    ::. ::   =..  :.-::: =:
>      .:-:-. -.::  ::=-:=:
>    ::::::=.  -.::   ===:       ::.
>      ::.:::=::=:   -===:--==-::--::
>        :.    :-=-.:==:.   .:  ::
>                 ===:       ::  :
>                 ==:
>                 ==
>                :==
>                -==:
>                -+=:
>                =++=.
>               .-===:

Re: U-Boot Concept Tree Proposal

[Simon Glass]

Hi Ilias,

On Thu, 4 Jun 2026 at 02:24, Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
>
> On Wed Jun 3, 2026 at 8:06 AM EEST, Simon Glass wrote:
> > Dear U-Boot Contributors,
>
> Hi Simon
>
> >
> > I would like to introduce the U-Boot Concept tree along with a few thoughts
> > on its role in U-Boot.
> >
> > By way of background, I have been a contributor for about 15 years - around
> > 10k commits and countless reviews. I have introduced many innovations into
> > the project: e.g. sandbox, device tree, C test infrastructure, Binman,
> > standard boot. Of course I could not have done any of this without the
> > U-Boot community (nor would there be any point).
> >
> > As the U-Boot project has matured, the demands for mainline stability and
> > rigorous review have created a natural friction for landing complex,
> > large-scale feature and refactoring series at the necessary pace. This
> > structural reality, which has slowed the adoption of ambitious efforts like
> > bootstd, VBE, xPL [1], and CI-connected hardware labs, is what the Concept
> > tree is designed to alleviate.
> >
>
> Well the problem here -- at least from my side, is that a lot of these features
> are useful but feel half baked. E.g we found bugs in the bootstd uefi method and
> those were not corner cases bugs. We couldn't even boot boards with it until [0].

From memory that was the work to allow booting an EFI app without
needing CONFIG_CMDLINE to be enabled. The Fixes tag on that commit
points to a commit by akashi.tkhro@gmail.com, not me (perhaps the
-next merge has bug though, but strange to add a Fixes tag for that?).
Certainly I was booting Ubuntu on a Chromebook using this long before
the end of 2023 (but yes, there were fixes to the original code, there
are always fixes).

>
> I also think to an extent that's expected. Introducing big features will carry bugs
> etc and that's fine. What's not fine is trying to merge all of them in a short
> period of time. We need to find a working model, where new features are tested,
> at least on a number of boards and become the default. Those changes also need
> to be sent incrementally and be reviewable. You can't send a 50 patch series and
> expect them to get merged in a week. You need to find a way to send smaller patches
> that people can reliably review and accept.
> FWIW there's similar code all over the place in the driver model.

Here i am talking about the Concept tree, rather than mainline. I hope
you will agree that for mainline I have been sending small series and
waiting for a while for them to be applied, before sending more. That
is certainly been what I've tried to do.

>
> The pattern here is that you add some code for an idea, but you spend little
> effort plugging it in to the rest of the ecosystem and boards. You just magically
> expect people to follow that and then you personally treat it as a U-Boot standard.

Most of the new features are independent of the board (e.g. code in
boot/ is generic). I did try very hard to enable VBE in rk3399, even
sending a rebased series a few weeks back, but it hasn't happened.
Perhaps I could do better, but it isn't for lack of effort.

>
> > I strongly believe that projects must evolve in order to stay relevant in
> > the long term. This includes code-refactoring, new features and subsystems,
> > along with migration of old code to use them.  A look back at the U-Boot of
> > 2010 shows how far the project has come. I don't think anyone would still
> > be using U-Boot if it had not evolved.
>
> Agree
>
> >
> > I have set up a 'Concept' tree, a possible future for U-Boot, as a way to
> > regain the old pace of innovation. This environment is a proving ground for
> > new features where we maintain a lower bar for risk tolerance and
> > completeness. We will accept partial and speculative features, provided the
> > underlying code remains robust and of high quality, with the shared
> > understanding that features may be dropped if they do not prove beneficial.
> >
> > 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.
>
> Do you plan to merge patches that were written and reviewed only by AI agents?

No, there needs to be human review by the author before the patches
are sent, then by reviewers. AI is just an assistant, although we'll
see what happens next year.

>
> > 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.
> >
> > Once features are landed and functional in Concept I hope that many will
> > find their way to mainline, although inevitably some rework will be needed.
> >
> > I recognise that introducing a new 'Concept' tree might initially cause
> > confusion or concern. This is an invitation to work together to define its
> > role. I welcome all feedback - positive or negative - here on the mailing
> > list, privately, or on irc. Let’s discuss how this initiative can help
> > U-Boot remain the defining firmware for the 2030s.
> >
> > [1]
> > https://lore.kernel.org/u-boot/CAFLszTg6sKpZ1yP3Pjgk9_Fx3MOh=ieT2oaHfgLf3_nC+xXA9g@mail.gmail.com/
> >
>
> [0] commit 4b151562bb8e541 ("bootmeth: pass size to efi_binary_run()")
>
> Thanks
> /Ilias
>
> > Concept tree:
> >                        :
> >                        ::
> >                      ...:::.
> >                  ::  :. -
> >            .   ::::::-  - ::. ..
> >           .:: .:      -==  =.:.
> >         ::.- ::::. ::. :=:. ::::
> >   ::. ::   =..  :.-::: =:
> >     .:-:-. -.::  ::=-:=:
> >   ::::::=.  -.::   ===:       ::.
> >     ::.:::=::=:   -===:--==-::--::
> >       :.    :-=-.:==:.   .:  ::
> >                ===:       ::  :
> >                ==:
> >                ==
> >               :==
> >               -==:
> >               -+=:
> >               =++=.
> >              .-===:
>

Regards,
Simon

Re: U-Boot Concept Tree Proposal

[Simon Glass]

Hi Neil,

On Thu, 4 Jun 2026 at 07:17, Neil Armstrong <neil.armstrong@linaro.org> wrote:
>
> Hi Simon,
>
> On 6/3/26 07:06, Simon Glass wrote:
> > Dear U-Boot Contributors,
> >
> > I would like to introduce the U-Boot Concept tree along with a few thoughts
> > on its role in U-Boot.
> >
> > By way of background, I have been a contributor for about 15 years - around
> > 10k commits and countless reviews. I have introduced many innovations into
> > the project: e.g. sandbox, device tree, C test infrastructure, Binman,
> > standard boot. Of course I could not have done any of this without the
> > U-Boot community (nor would there be any point).
> >
> > As the U-Boot project has matured, the demands for mainline stability and
> > rigorous review have created a natural friction for landing complex,
> > large-scale feature and refactoring series at the necessary pace. This
> > structural reality, which has slowed the adoption of ambitious efforts like
> > bootstd, VBE, xPL [1], and CI-connected hardware labs, is what the Concept
> > tree is designed to alleviate.
>
> The main issue to land complex large-scale feature and refactoring series is
> mainly the lack of human highly qualified reviewers, proper shared project
> infrastructure and funding for paid work. Not developers.

That's not quite what I am seeing. I am actually seeing quite a bit of
rejection and deferring. Perhaps that is just because of what you are
saying, but in any case, it is creating challenges.

Re infrastructure, I am already providing a lot. I have offered to Tom
to help with other pieces, if needed.

>
> >
> > I strongly believe that projects must evolve in order to stay relevant in
> > the long term. This includes code-refactoring, new features and subsystems,
> > along with migration of old code to use them.  A look back at the U-Boot of
> > 2010 shows how far the project has come. I don't think anyone would still
> > be using U-Boot if it had not evolved.
> >
> > I have set up a 'Concept' tree, a possible future for U-Boot, as a way to
> > regain the old pace of innovation. This environment is a proving ground for
> > new features where we maintain a lower bar for risk tolerance and
> > completeness. We will accept partial and speculative features, provided the
> > underlying code remains robust and of high quality, with the shared
> > understanding that features may be dropped if they do not prove beneficial.
>
> I'm clearly against having a separate official "U-Boot" fork tree, this will
> only lead to confusion to users and contributors if it shares the same
> mailing-list and name.

Yes it cannot share the same mailing list - we tried that last year.
Do you think "U-Boot Concept Tree' is different enough for "U-Boot",
to avoid confusion?

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

>
> >
> > Once features are landed and functional in Concept I hope that many will
> > find their way to mainline, although inevitably some rework will be needed.
>
> Still I don't understand your point, Linux or Zephyr can land very complex
> features with a single tree, what make U-Boot different here ?

I made some guesses above ("the demands for mainline stability and
rigorous review"), but I'm open to your thoughts on the root cause.

No project is immune though. I worked a lot in Zephyr - one-hour
meetings every week across several areas, lots of engagement, but even
then one feature we did took over two years to land (luckily the
company could afford the cost :-) You may be aware that FIT (a fairly
minor feature) was kept out of the kernel for 15+ years. Another
example is perhaps the bootph tags. I introduced these into U-Boot in
2015 and found their way into linux around 7 years later.

>
> >
> > I recognise that introducing a new 'Concept' tree might initially cause
> > confusion or concern. This is an invitation to work together to define its
> > role. I welcome all feedback - positive or negative - here on the mailing
> > list, privately, or on irc. Let’s discuss how this initiative can help
> > U-Boot remain the defining firmware for the 2030s.
>
> Our immediate priority is helping U-Boot establish the proper technical and
> legal infrastructure to receive funding. Adding AI features, maintaining
> separate forks, and managing competing domains only distracts us from the
> critical task of switching off the dying Denx infrastructure.

I am not aware of what is going on there, but am happy to learn about
it if you can share details. From my experience, apart from patchwork
being down quite a bit, the infra is mostly holding up. In any case
you seem to be making my point about the limited bandwidth people have
to land features.

>
> This is my personal opinion,
> Neil

Yes, understood.

Regards,
- Simon


>
> >
> > [1]
> > https://lore.kernel.org/u-boot/CAFLszTg6sKpZ1yP3Pjgk9_Fx3MOh=ieT2oaHfgLf3_nC+xXA9g@mail.gmail.com/
> >
> > Concept tree:
> >                         :
> >                         ::
> >                       ...:::.
> >                   ::  :. -
> >             .   ::::::-  - ::. ..
> >            .:: .:      -==  =.:.
> >          ::.- ::::. ::. :=:. ::::
> >    ::. ::   =..  :.-::: =:
> >      .:-:-. -.::  ::=-:=:
> >    ::::::=.  -.::   ===:       ::.
> >      ::.:::=::=:   -===:--==-::--::
> >        :.    :-=-.:==:.   .:  ::
> >                 ===:       ::  :
> >                 ==:
> >                 ==
> >                :==
> >                -==:
> >                -+=:
> >                =++=.
> >               .-===:
>

Re: U-Boot Concept Tree Proposal

[Peter Robinson]

Hi Simon,

> > > I would like to introduce the U-Boot Concept tree along with a few thoughts
> > > on its role in U-Boot.
> > >
> > > By way of background, I have been a contributor for about 15 years - around
> > > 10k commits and countless reviews. I have introduced many innovations into
> > > the project: e.g. sandbox, device tree, C test infrastructure, Binman,
> > > standard boot. Of course I could not have done any of this without the
> > > U-Boot community (nor would there be any point).
> > >
> > > As the U-Boot project has matured, the demands for mainline stability and
> > > rigorous review have created a natural friction for landing complex,
> > > large-scale feature and refactoring series at the necessary pace. This
> > > structural reality, which has slowed the adoption of ambitious efforts like
> > > bootstd, VBE, xPL [1], and CI-connected hardware labs, is what the Concept
> > > tree is designed to alleviate.
> >
> > The main issue to land complex large-scale feature and refactoring series is
> > mainly the lack of human highly qualified reviewers, proper shared project
> > infrastructure and funding for paid work. Not developers.
>
> That's not quite what I am seeing. I am actually seeing quite a bit of
> rejection and deferring. Perhaps that is just because of what you are
> saying, but in any case, it is creating challenges.

Well maybe others in the community don't see the value it provides.
Not everyone sees ideas of others as good ideas, people have varying
opinions on them, that's fine, but we as a community decide what lands
and what doesn't, some times we as a community disagree and that's
fine. Not every idea will land upstream and that's not necessarily a
bad think. For example I see little value in mouse support in an early
bootloader.

> Re infrastructure, I am already providing a lot. I have offered to Tom
> to help with other pieces, if needed.
>
> >
> > >
> > > I strongly believe that projects must evolve in order to stay relevant in
> > > the long term. This includes code-refactoring, new features and subsystems,
> > > along with migration of old code to use them.  A look back at the U-Boot of
> > > 2010 shows how far the project has come. I don't think anyone would still
> > > be using U-Boot if it had not evolved.
> > >
> > > I have set up a 'Concept' tree, a possible future for U-Boot, as a way to
> > > regain the old pace of innovation. This environment is a proving ground for
> > > new features where we maintain a lower bar for risk tolerance and
> > > completeness. We will accept partial and speculative features, provided the
> > > underlying code remains robust and of high quality, with the shared
> > > understanding that features may be dropped if they do not prove beneficial.
> >
> > I'm clearly against having a separate official "U-Boot" fork tree, this will
> > only lead to confusion to users and contributors if it shares the same
> > mailing-list and name.
>
> Yes it cannot share the same mailing list - we tried that last year.
> Do you think "U-Boot Concept Tree' is different enough for "U-Boot",
> to avoid confusion?

The time where it should share the same mailing list is when patches
are moving from your concept to the main tree when undergoing review.
Do the patches your pushing to your concept tree need to be sent to a
mailing list?

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

Also it seems you are even using AI to reply to people on serious
mailing list things, I have concerns of your use of it there too!

> > > Once features are landed and functional in Concept I hope that many will
> > > find their way to mainline, although inevitably some rework will be needed.
> >
> > Still I don't understand your point, Linux or Zephyr can land very complex
> > features with a single tree, what make U-Boot different here ?
>
> I made some guesses above ("the demands for mainline stability and
> rigorous review"), but I'm open to your thoughts on the root cause.

I made some guesses above too.

> No project is immune though. I worked a lot in Zephyr - one-hour
> meetings every week across several areas, lots of engagement, but even
> then one feature we did took over two years to land (luckily the
> company could afford the cost :-) You may be aware that FIT (a fairly
> minor feature) was kept out of the kernel for 15+ years. Another
> example is perhaps the bootph tags. I introduced these into U-Boot in
> 2015 and found their way into linux around 7 years later.

So some time things take time, if they're not right or ready I don't
see the problem there. If there's demand for it people tend to find
the time to review it to move things forward.

> > > I recognise that introducing a new 'Concept' tree might initially cause
> > > confusion or concern. This is an invitation to work together to define its
> > > role. I welcome all feedback - positive or negative - here on the mailing
> > > list, privately, or on irc. Let’s discuss how this initiative can help
> > > U-Boot remain the defining firmware for the 2030s.
> >
> > Our immediate priority is helping U-Boot establish the proper technical and
> > legal infrastructure to receive funding. Adding AI features, maintaining
> > separate forks, and managing competing domains only distracts us from the
> > critical task of switching off the dying Denx infrastructure.
>
> I am not aware of what is going on there, but am happy to learn about
> it if you can share details. From my experience, apart from patchwork
> being down quite a bit, the infra is mostly holding up. In any case
> you seem to be making my point about the limited bandwidth people have
> to land features.

The infrastructure really isn't holding up, the patchwork is run by
ozlabs and is currently unrelated. We have a deadline on the denx
infrastructure and your failure to hand over the domain hasn't helped
there.

Peter

Re: U-Boot Concept Tree Proposal

[Simon Glass]

Hi Peter,

On Fri, 12 Jun 2026 at 19:33, Peter Robinson <pbrobinson@gmail.com> wrote:
>
> Hi Simon,
>
> > > > I would like to introduce the U-Boot Concept tree along with a few thoughts
> > > > on its role in U-Boot.
> > > >
> > > > By way of background, I have been a contributor for about 15 years - around
> > > > 10k commits and countless reviews. I have introduced many innovations into
> > > > the project: e.g. sandbox, device tree, C test infrastructure, Binman,
> > > > standard boot. Of course I could not have done any of this without the
> > > > U-Boot community (nor would there be any point).
> > > >
> > > > As the U-Boot project has matured, the demands for mainline stability and
> > > > rigorous review have created a natural friction for landing complex,
> > > > large-scale feature and refactoring series at the necessary pace. This
> > > > structural reality, which has slowed the adoption of ambitious efforts like
> > > > bootstd, VBE, xPL [1], and CI-connected hardware labs, is what the Concept
> > > > tree is designed to alleviate.
> > >
> > > The main issue to land complex large-scale feature and refactoring series is
> > > mainly the lack of human highly qualified reviewers, proper shared project
> > > infrastructure and funding for paid work. Not developers.
> >
> > That's not quite what I am seeing. I am actually seeing quite a bit of
> > rejection and deferring. Perhaps that is just because of what you are
> > saying, but in any case, it is creating challenges.
>
> Well maybe others in the community don't see the value it provides.
> Not everyone sees ideas of others as good ideas, people have varying
> opinions on them, that's fine, but we as a community decide what lands
> and what doesn't, some times we as a community disagree and that's
> fine. Not every idea will land upstream and that's not necessarily a
> bad think. For example I see little value in mouse support in an early
> bootloader.

I agree to some extent, but in general I believe that code should
land. U-Boot is a general-purpose project and we have quirks for all
sorts of hardware and situations. Better to bring it in an solve the
problem properly and generally, than force vendors and users into
using downstream versions.

U-Boot (Concept at least) can be built as an EFI app and therefore
replace GRUB, so it isn't necessarily an 'early' bootloader. When
running on embedded hardware where Linux is installed using
u-boot-menu or systemd-boot (ie. extlinux / 'boot loader
specification' (BLS)), a mouse and proper display also allow
dispensing with GRUB and even EFI.

>
> > Re infrastructure, I am already providing a lot. I have offered to Tom
> > to help with other pieces, if needed.
> >
> > >
> > > >
> > > > I strongly believe that projects must evolve in order to stay relevant in
> > > > the long term. This includes code-refactoring, new features and subsystems,
> > > > along with migration of old code to use them.  A look back at the U-Boot of
> > > > 2010 shows how far the project has come. I don't think anyone would still
> > > > be using U-Boot if it had not evolved.
> > > >
> > > > I have set up a 'Concept' tree, a possible future for U-Boot, as a way to
> > > > regain the old pace of innovation. This environment is a proving ground for
> > > > new features where we maintain a lower bar for risk tolerance and
> > > > completeness. We will accept partial and speculative features, provided the
> > > > underlying code remains robust and of high quality, with the shared
> > > > understanding that features may be dropped if they do not prove beneficial.
> > >
> > > I'm clearly against having a separate official "U-Boot" fork tree, this will
> > > only lead to confusion to users and contributors if it shares the same
> > > mailing-list and name.
> >
> > Yes it cannot share the same mailing list - we tried that last year.
> > Do you think "U-Boot Concept Tree' is different enough for "U-Boot",
> > to avoid confusion?
>
> The time where it should share the same mailing list is when patches
> are moving from your concept to the main tree when undergoing review.
> Do the patches your pushing to your concept tree need to be sent to a
> mailing list?

That has been my approach to date. Even if not, though, I think a
separate mailing list makes sense, to avoid confusing people.

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

>
> Also it seems you are even using AI to reply to people on serious
> mailing list things, I have concerns of your use of it there too!

Yes I use Patman to at least queue up some of my reviews for code. But
it is a long way from being a substitute for my own review...we'll see
what happens and I admit I have not put much effort into a full AI
reviewer - at minimum we would need lots of written rules whereas for
now it mostly relies on the patterns it sees in the tree.

>
> > > > Once features are landed and functional in Concept I hope that many will
> > > > find their way to mainline, although inevitably some rework will be needed.
> > >
> > > Still I don't understand your point, Linux or Zephyr can land very complex
> > > features with a single tree, what make U-Boot different here ?
> >
> > I made some guesses above ("the demands for mainline stability and
> > rigorous review"), but I'm open to your thoughts on the root cause.
>
> I made some guesses above too.
>
> > No project is immune though. I worked a lot in Zephyr - one-hour
> > meetings every week across several areas, lots of engagement, but even
> > then one feature we did took over two years to land (luckily the
> > company could afford the cost :-) You may be aware that FIT (a fairly
> > minor feature) was kept out of the kernel for 15+ years. Another
> > example is perhaps the bootph tags. I introduced these into U-Boot in
> > 2015 and found their way into linux around 7 years later.
>
> So some time things take time, if they're not right or ready I don't
> see the problem there. If there's demand for it people tend to find
> the time to review it to move things forward.

To me that is a quite a rosy view of things, TBH.

>
> > > > I recognise that introducing a new 'Concept' tree might initially cause
> > > > confusion or concern. This is an invitation to work together to define its
> > > > role. I welcome all feedback - positive or negative - here on the mailing
> > > > list, privately, or on irc. Let’s discuss how this initiative can help
> > > > U-Boot remain the defining firmware for the 2030s.
> > >
> > > Our immediate priority is helping U-Boot establish the proper technical and
> > > legal infrastructure to receive funding. Adding AI features, maintaining
> > > separate forks, and managing competing domains only distracts us from the
> > > critical task of switching off the dying Denx infrastructure.
> >
> > I am not aware of what is going on there, but am happy to learn about
> > it if you can share details. From my experience, apart from patchwork
> > being down quite a bit, the infra is mostly holding up. In any case
> > you seem to be making my point about the limited bandwidth people have
> > to land features.
>
> The infrastructure really isn't holding up, the patchwork is run by
> ozlabs and is currently unrelated. We have a deadline on the denx
> infrastructure and your failure to hand over the domain hasn't helped
> there.

OK, well it seems we have figured this out, so I hope it can also get
done before the deadline. I'll reply separately.

Regards,
Simon

Re: U-Boot Concept Tree Proposal

[Simon Glass]

Hi,

On Wed, 3 Jun 2026 at 06:06, Simon Glass <sjg@chromium.org> wrote:
>
> Dear U-Boot Contributors,
>
> I would like to introduce the U-Boot Concept tree along with a few thoughts on its role in U-Boot.
>
> By way of background, I have been a contributor for about 15 years - around 10k commits and countless reviews. I have introduced many innovations into the project: e.g. sandbox, device tree, C test infrastructure, Binman, standard boot. Of course I could not have done any of this without the U-Boot community (nor would there be any point).
>
> As the U-Boot project has matured, the demands for mainline stability and rigorous review have created a natural friction for landing complex, large-scale feature and refactoring series at the necessary pace. This structural reality, which has slowed the adoption of ambitious efforts like bootstd, VBE, xPL [1], and CI-connected hardware labs, is what the Concept tree is designed to alleviate.
>
> I strongly believe that projects must evolve in order to stay relevant in the long term. This includes code-refactoring, new features and subsystems, along with migration of old code to use them.  A look back at the U-Boot of 2010 shows how far the project has come. I don't think anyone would still be using U-Boot if it had not evolved.
>
> I have set up a 'Concept' tree, a possible future for U-Boot, as a way to regain the old pace of innovation. This environment is a proving ground for new features where we maintain a lower bar for risk tolerance and completeness. We will accept partial and speculative features, provided the underlying code remains robust and of high quality, with the shared understanding that features may be dropped if they do not prove beneficial.
>
> 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.
>
> Once features are landed and functional in Concept I hope that many will find their way to mainline, although inevitably some rework will be needed.
>
> I recognise that introducing a new 'Concept' tree might initially cause confusion or concern. This is an invitation to work together to define its role. I welcome all feedback - positive or negative - here on the mailing list, privately, or on irc. Let’s discuss how this initiative can help U-Boot remain the defining firmware for the 2030s.
>
> [1]  https://lore.kernel.org/u-boot/CAFLszTg6sKpZ1yP3Pjgk9_Fx3MOh=ieT2oaHfgLf3_nC+xXA9g@mail.gmail.com/

Just to report that after some brief discussions, we have agreed on a
path forward here (thank you Peter!).

Concept will become a custodian tree in U-Boot's Gitlab instance. I
will run it, with access to my hardware lab. It will cherry-pick from
mainline and accept code through its own channels (PRs and separate
mailing list + patchwork). When features are ready for mainline, I
will send patches to the main list for review in the normal way.

I have been working to migrate things off u-boot.org (lab, gitlab,
blog... and email). I am transferring u-boot.org to the SFC once this
is finished in the next few days. If we do end up setting up email
addresses for people on u-boot.org, I'd appreciate keeping sjg@

Tom, Neil Peter, please can you ack this to confirm you are happy with it?

>
> Concept tree:
>                        :
>                        ::
>                      ...:::.
>                  ::  :. -
>            .   ::::::-  - ::. ..
>           .:: .:      -==  =.:.
>         ::.- ::::. ::. :=:. ::::
>   ::. ::   =..  :.-::: =:
>     .:-:-. -.::  ::=-:=:
>   ::::::=.  -.::   ===:       ::.
>     ::.:::=::=:   -===:--==-::--::
>       :.    :-=-.:==:.   .:  ::
>                ===:       ::  :
>                ==:
>                ==
>               :==
>               -==:
>               -+=:
>               =++=.
>              .-===:

Regards,
Simon

Re: U-Boot Concept Tree Proposal

[Simon Glass]

Adding to cc

On Thu, 18 Jun 2026, 16:08 Simon Glass, <sjg@chromium.org> wrote:

> Hi,
>
> On Wed, 3 Jun 2026 at 06:06, Simon Glass <sjg@chromium.org> wrote:
> >
> > Dear U-Boot Contributors,
> >
> > I would like to introduce the U-Boot Concept tree along with a few
> thoughts on its role in U-Boot.
> >
> > By way of background, I have been a contributor for about 15 years -
> around 10k commits and countless reviews. I have introduced many
> innovations into the project: e.g. sandbox, device tree, C test
> infrastructure, Binman, standard boot. Of course I could not have done any
> of this without the U-Boot community (nor would there be any point).
> >
> > As the U-Boot project has matured, the demands for mainline stability
> and rigorous review have created a natural friction for landing complex,
> large-scale feature and refactoring series at the necessary pace. This
> structural reality, which has slowed the adoption of ambitious efforts like
> bootstd, VBE, xPL [1], and CI-connected hardware labs, is what the Concept
> tree is designed to alleviate.
> >
> > I strongly believe that projects must evolve in order to stay relevant
> in the long term. This includes code-refactoring, new features and
> subsystems, along with migration of old code to use them.  A look back at
> the U-Boot of 2010 shows how far the project has come. I don't think anyone
> would still be using U-Boot if it had not evolved.
> >
> > I have set up a 'Concept' tree, a possible future for U-Boot, as a way
> to regain the old pace of innovation. This environment is a proving ground
> for new features where we maintain a lower bar for risk tolerance and
> completeness. We will accept partial and speculative features, provided the
> underlying code remains robust and of high quality, with the shared
> understanding that features may be dropped if they do not prove beneficial.
> >
> > 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.
> >
> > Once features are landed and functional in Concept I hope that many will
> find their way to mainline, although inevitably some rework will be needed.
> >
> > I recognise that introducing a new 'Concept' tree might initially cause
> confusion or concern. This is an invitation to work together to define its
> role. I welcome all feedback - positive or negative - here on the mailing
> list, privately, or on irc. Let’s discuss how this initiative can help
> U-Boot remain the defining firmware for the 2030s.
> >
> > [1]
> https://lore.kernel.org/u-boot/CAFLszTg6sKpZ1yP3Pjgk9_Fx3MOh=ieT2oaHfgLf3_nC+xXA9g@mail.gmail.com/
>
> Just to report that after some brief discussions, we have agreed on a
> path forward here (thank you Peter!).
>
> Concept will become a custodian tree in U-Boot's Gitlab instance. I
> will run it, with access to my hardware lab. It will cherry-pick from
> mainline and accept code through its own channels (PRs and separate
> mailing list + patchwork). When features are ready for mainline, I
> will send patches to the main list for review in the normal way.
>
> I have been working to migrate things off u-boot.org (lab, gitlab,
> blog... and email). I am transferring u-boot.org to the SFC once this
> is finished in the next few days. If we do end up setting up email
> addresses for people on u-boot.org, I'd appreciate keeping sjg@
>
> Tom, Neil Peter, please can you ack this to confirm you are happy with it?
>
> >
> > Concept tree:
> >                        :
> >                        ::
> >                      ...:::.
> >                  ::  :. -
> >            .   ::::::-  - ::. ..
> >           .:: .:      -==  =.:.
> >         ::.- ::::. ::. :=:. ::::
> >   ::. ::   =..  :.-::: =:
> >     .:-:-. -.::  ::=-:=:
> >   ::::::=.  -.::   ===:       ::.
> >     ::.:::=::=:   -===:--==-::--::
> >       :.    :-=-.:==:.   .:  ::
> >                ===:       ::  :
> >                ==:
> >                ==
> >               :==
> >               -==:
> >               -+=:
> >               =++=.
> >              .-===:
>
> Regards,
> Simon
>

Re: U-Boot Concept Tree Proposal

[Neil Armstrong]

On 6/18/26 17:08, Simon Glass wrote:
> Hi,
> 
> On Wed, 3 Jun 2026 at 06:06, Simon Glass <sjg@chromium.org> wrote:
>>
>> Dear U-Boot Contributors,
>>
>> I would like to introduce the U-Boot Concept tree along with a few thoughts on its role in U-Boot.
>>
>> By way of background, I have been a contributor for about 15 years - around 10k commits and countless reviews. I have introduced many innovations into the project: e.g. sandbox, device tree, C test infrastructure, Binman, standard boot. Of course I could not have done any of this without the U-Boot community (nor would there be any point).
>>
>> As the U-Boot project has matured, the demands for mainline stability and rigorous review have created a natural friction for landing complex, large-scale feature and refactoring series at the necessary pace. This structural reality, which has slowed the adoption of ambitious efforts like bootstd, VBE, xPL [1], and CI-connected hardware labs, is what the Concept tree is designed to alleviate.
>>
>> I strongly believe that projects must evolve in order to stay relevant in the long term. This includes code-refactoring, new features and subsystems, along with migration of old code to use them.  A look back at the U-Boot of 2010 shows how far the project has come. I don't think anyone would still be using U-Boot if it had not evolved.
>>
>> I have set up a 'Concept' tree, a possible future for U-Boot, as a way to regain the old pace of innovation. This environment is a proving ground for new features where we maintain a lower bar for risk tolerance and completeness. We will accept partial and speculative features, provided the underlying code remains robust and of high quality, with the shared understanding that features may be dropped if they do not prove beneficial.
>>
>> 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.
>>
>> Once features are landed and functional in Concept I hope that many will find their way to mainline, although inevitably some rework will be needed.
>>
>> I recognise that introducing a new 'Concept' tree might initially cause confusion or concern. This is an invitation to work together to define its role. I welcome all feedback - positive or negative - here on the mailing list, privately, or on irc. Let’s discuss how this initiative can help U-Boot remain the defining firmware for the 2030s.
>>
>> [1]  https://lore.kernel.org/u-boot/CAFLszTg6sKpZ1yP3Pjgk9_Fx3MOh=ieT2oaHfgLf3_nC+xXA9g@mail.gmail.com/
> 
> Just to report that after some brief discussions, we have agreed on a
> path forward here (thank you Peter!).
> 
> Concept will become a custodian tree in U-Boot's Gitlab instance. I
> will run it, with access to my hardware lab. It will cherry-pick from
> mainline and accept code through its own channels (PRs and separate
> mailing list + patchwork). When features are ready for mainline, I
> will send patches to the main list for review in the normal way.
> 
> I have been working to migrate things off u-boot.org (lab, gitlab,
> blog... and email). I am transferring u-boot.org to the SFC once this
> is finished in the next few days. If we do end up setting up email
> addresses for people on u-boot.org, I'd appreciate keeping sjg@
> 
> Tom, Neil Peter, please can you ack this to confirm you are happy with it?

As we already discussed in private, that approach works for me.

Thanks,
Neil

> 
>>
>> Concept tree:
>>                         :
>>                         ::
>>                       ...:::.
>>                   ::  :. -
>>             .   ::::::-  - ::. ..
>>            .:: .:      -==  =.:.
>>          ::.- ::::. ::. :=:. ::::
>>    ::. ::   =..  :.-::: =:
>>      .:-:-. -.::  ::=-:=:
>>    ::::::=.  -.::   ===:       ::.
>>      ::.:::=::=:   -===:--==-::--::
>>        :.    :-=-.:==:.   .:  ::
>>                 ===:       ::  :
>>                 ==:
>>                 ==
>>                :==
>>                -==:
>>                -+=:
>>                =++=.
>>               .-===:
> 
> Regards,
> Simon

Re: U-Boot Concept Tree Proposal

[Peter Robinson]

On Thu, 18 Jun 2026 at 16:19, Simon Glass <sjg@chromium.org> wrote:
>
> Hi,
>
> On Wed, 3 Jun 2026 at 06:06, Simon Glass <sjg@chromium.org> wrote:
> >
> > Dear U-Boot Contributors,
> >
> > I would like to introduce the U-Boot Concept tree along with a few thoughts on its role in U-Boot.
> >
> > By way of background, I have been a contributor for about 15 years - around 10k commits and countless reviews. I have introduced many innovations into the project: e.g. sandbox, device tree, C test infrastructure, Binman, standard boot. Of course I could not have done any of this without the U-Boot community (nor would there be any point).
> >
> > As the U-Boot project has matured, the demands for mainline stability and rigorous review have created a natural friction for landing complex, large-scale feature and refactoring series at the necessary pace. This structural reality, which has slowed the adoption of ambitious efforts like bootstd, VBE, xPL [1], and CI-connected hardware labs, is what the Concept tree is designed to alleviate.
> >
> > I strongly believe that projects must evolve in order to stay relevant in the long term. This includes code-refactoring, new features and subsystems, along with migration of old code to use them.  A look back at the U-Boot of 2010 shows how far the project has come. I don't think anyone would still be using U-Boot if it had not evolved.
> >
> > I have set up a 'Concept' tree, a possible future for U-Boot, as a way to regain the old pace of innovation. This environment is a proving ground for new features where we maintain a lower bar for risk tolerance and completeness. We will accept partial and speculative features, provided the underlying code remains robust and of high quality, with the shared understanding that features may be dropped if they do not prove beneficial.
> >
> > 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.
> >
> > Once features are landed and functional in Concept I hope that many will find their way to mainline, although inevitably some rework will be needed.
> >
> > I recognise that introducing a new 'Concept' tree might initially cause confusion or concern. This is an invitation to work together to define its role. I welcome all feedback - positive or negative - here on the mailing list, privately, or on irc. Let’s discuss how this initiative can help U-Boot remain the defining firmware for the 2030s.
> >
> > [1]  https://lore.kernel.org/u-boot/CAFLszTg6sKpZ1yP3Pjgk9_Fx3MOh=ieT2oaHfgLf3_nC+xXA9g@mail.gmail.com/
>
> Just to report that after some brief discussions, we have agreed on a
> path forward here (thank you Peter!).
>
> Concept will become a custodian tree in U-Boot's Gitlab instance. I
> will run it, with access to my hardware lab. It will cherry-pick from
> mainline and accept code through its own channels (PRs and separate
> mailing list + patchwork). When features are ready for mainline, I
> will send patches to the main list for review in the normal way.

Thanks not entirely what I envisioned with the custodian tree, cherry
pickign from mainline and accepting PRs is very much a fork in my
opinion.

My intention was that it's a place for you to collaborate with others
on feature branches to get them to a point they are ready to go out
for review to go into mainline, not pull features from others etc
which sounds like to me a fork of stuff that may not reach mainline.

> I have been working to migrate things off u-boot.org (lab, gitlab,
> blog... and email). I am transferring u-boot.org to the SFC once this
> is finished in the next few days. If we do end up setting up email
> addresses for people on u-boot.org, I'd appreciate keeping sjg@

As I've stated elsewhere the only emails will be for the admin
required for the running of the project as a whole.

> Tom, Neil Peter, please can you ack this to confirm you are happy with it?

With the caveats outlined above, basically yes.

> >
> > Concept tree:
> >                        :
> >                        ::
> >                      ...:::.
> >                  ::  :. -
> >            .   ::::::-  - ::. ..
> >           .:: .:      -==  =.:.
> >         ::.- ::::. ::. :=:. ::::
> >   ::. ::   =..  :.-::: =:
> >     .:-:-. -.::  ::=-:=:
> >   ::::::=.  -.::   ===:       ::.
> >     ::.:::=::=:   -===:--==-::--::
> >       :.    :-=-.:==:.   .:  ::
> >                ===:       ::  :
> >                ==:
> >                ==
> >               :==
> >               -==:
> >               -+=:
> >               =++=.
> >              .-===:
>
> Regards,
> Simon

Re: U-Boot Concept Tree Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 5062 bytes --]

On Mon, Jun 22, 2026 at 03:32:21PM +0100, Peter Robinson wrote:
> On Thu, 18 Jun 2026 at 16:19, Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi,
> >
> > On Wed, 3 Jun 2026 at 06:06, Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Dear U-Boot Contributors,
> > >
> > > I would like to introduce the U-Boot Concept tree along with a few thoughts on its role in U-Boot.
> > >
> > > By way of background, I have been a contributor for about 15 years - around 10k commits and countless reviews. I have introduced many innovations into the project: e.g. sandbox, device tree, C test infrastructure, Binman, standard boot. Of course I could not have done any of this without the U-Boot community (nor would there be any point).
> > >
> > > As the U-Boot project has matured, the demands for mainline stability and rigorous review have created a natural friction for landing complex, large-scale feature and refactoring series at the necessary pace. This structural reality, which has slowed the adoption of ambitious efforts like bootstd, VBE, xPL [1], and CI-connected hardware labs, is what the Concept tree is designed to alleviate.
> > >
> > > I strongly believe that projects must evolve in order to stay relevant in the long term. This includes code-refactoring, new features and subsystems, along with migration of old code to use them.  A look back at the U-Boot of 2010 shows how far the project has come. I don't think anyone would still be using U-Boot if it had not evolved.
> > >
> > > I have set up a 'Concept' tree, a possible future for U-Boot, as a way to regain the old pace of innovation. This environment is a proving ground for new features where we maintain a lower bar for risk tolerance and completeness. We will accept partial and speculative features, provided the underlying code remains robust and of high quality, with the shared understanding that features may be dropped if they do not prove beneficial.
> > >
> > > 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.
> > >
> > > Once features are landed and functional in Concept I hope that many will find their way to mainline, although inevitably some rework will be needed.
> > >
> > > I recognise that introducing a new 'Concept' tree might initially cause confusion or concern. This is an invitation to work together to define its role. I welcome all feedback - positive or negative - here on the mailing list, privately, or on irc. Let’s discuss how this initiative can help U-Boot remain the defining firmware for the 2030s.
> > >
> > > [1]  https://lore.kernel.org/u-boot/CAFLszTg6sKpZ1yP3Pjgk9_Fx3MOh=ieT2oaHfgLf3_nC+xXA9g@mail.gmail.com/
> >
> > Just to report that after some brief discussions, we have agreed on a
> > path forward here (thank you Peter!).
> >
> > Concept will become a custodian tree in U-Boot's Gitlab instance. I
> > will run it, with access to my hardware lab. It will cherry-pick from
> > mainline and accept code through its own channels (PRs and separate
> > mailing list + patchwork). When features are ready for mainline, I
> > will send patches to the main list for review in the normal way.
> 
> Thanks not entirely what I envisioned with the custodian tree, cherry
> pickign from mainline and accepting PRs is very much a fork in my
> opinion.
> 
> My intention was that it's a place for you to collaborate with others
> on feature branches to get them to a point they are ready to go out
> for review to go into mainline, not pull features from others etc
> which sounds like to me a fork of stuff that may not reach mainline.
> 
> > I have been working to migrate things off u-boot.org (lab, gitlab,
> > blog... and email). I am transferring u-boot.org to the SFC once this
> > is finished in the next few days. If we do end up setting up email
> > addresses for people on u-boot.org, I'd appreciate keeping sjg@
> 
> As I've stated elsewhere the only emails will be for the admin
> required for the running of the project as a whole.
> 
> > Tom, Neil Peter, please can you ack this to confirm you are happy with it?
> 
> With the caveats outlined above, basically yes.

I've been quiet on this thread as I think I've already put more than
enough words out already about this situation. So to repeat what Peter
said, yes, a custodian tree (which is a well defined thing for the last
two decades, predating both of us in the project) but not a parallel
and divergent tree.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: U-Boot Concept Tree Proposal

[Quentin Schulz]

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

Re: U-Boot Concept Tree Proposal

[Simon Glass]

Hi Quentin,

On Fri, 26 Jun 2026 at 19:07, Quentin Schulz <quentin.schulz@cherry.de> wrote:
>
> 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.
> >

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

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

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

A key challenge IMO is reviewers / maintainers (and authors!!) of
generic code. We have maintainers who handle archs and some areas. We
lack people who are willing to dig into unfamiliar code, figure out
how it should work and review / send patches. It is thankless work in
many cases - I can attest to that, having done many thousands of
reviews.

Speaking for myself, I would be encouraged to spend more time on
reviews if I had a stronger sense of ownership of a particular
subsystem (and ability to get PRs accepted).

Out of interest I tried to list the top reviewers in somehat generic
directories (anyone who has done at least 50 reviews in an area):

EXCLUDE=board,include,configs,arch/arm/dts ./review-stats.sh 20 50
reviews commits  name                 top review areas (# reviews)
   7224   10576  Simon Glass          common(699), test(665),
doc(519), lib(452), tools(447), cmd(447), arch/x86(378),
arch/sandbox(273), drivers/core(204), scripts(197),
arch/arm/include(184), drivers/video(181), drivers/serial(180),
boot(134), drivers/clk(131), drivers/mmc(129), drivers/gpio(126),
arch/arm/cpu(123), drivers/net(117), Makefile(116), drivers/usb(113),
drivers/power(110), drivers/pinctrl(109), drivers/mtd(105),
MAINTAINERS(101), arch/arm/mach-rockchip(96), drivers/pci(89),
net(86), drivers/spi(83), drivers/misc(80), arch/mips(75), README(73),
arch/powerpc(72), arch/arm/Kconfig(66), fs(65), drivers/timer(65),
drivers/i2c(65), arch/arm/mach-tegra(58), arch/arm/lib(58),
drivers/block(54), Kconfig(53), env(52)
   2953    4094  Tom Rini             common(352), arch/arm/cpu(224),
arch/arm/include(200), cmd(159), lib(124), tools(113), doc(101),
arch/arm/mach-omap2(94), scripts(92), boot(79), drivers/mmc(68),
arch/arm/Kconfig(65), test(60), README(60), drivers/net(56),
drivers/usb(52), arch/arm/mach-keystone(52)
   2675    1611  Bin Meng             arch/x86(839), cmd(180),
doc(164), drivers/pci(143), arch/riscv(135), common(133), lib(122),
test(95), scripts(65), drivers/net(60), tools(57), drivers/core(55),
arch/sandbox(52)
   1907     540  Kever Yang           arch/arm/mach-rockchip(343),
doc(132), drivers/ram(93), drivers/clk(90), arch/arm/include(90),
dts(89), drivers/phy(53)
   1703    1702  Stefan Roese         tools(190),
arch/arm/mach-mvebu(142), drivers/watchdog(94), drivers/pci(91),
common(71), cmd(66), drivers/net(61)
   1484     578  York Sun             arch/arm/cpu(277),
arch/arm/include(242), arch/powerpc(196), drivers/net(141)
    996    1036  Jagan Teki           drivers/mtd(221),
drivers/spi(208), arch/arm/mach-sunxi(65)
    875     679  Patrice Chotard      arch/arm/mach-stm32mp(183)
    829     123  Priyanka Jain        arch/powerpc(131),
arch/arm/cpu(65), drivers/net(58)
    813    1281  Fabio Estevam        arch/arm/mach-imx(147),
arch/arm/include(63)
    768    3054  Heinrich Schuchardt  lib(348), doc(136), cmd(86)
    746    4354  Marek Vasut          drivers/usb(207), common(75)
    697     327  Ilias Apalodimas     lib(334), cmd(94)
    674    1381  Peng Fan             arch/arm/mach-imx(160),
drivers/mmc(80), arch/arm/include(54)
    605     743  Heiko Schocher       drivers/i2c(194), common(51)
    515    1180  Patrick Delaunay     arch/arm/mach-stm32mp(79)
    478     381  Philipp Tomsich      arch/arm/mach-rockchip(84)
    455      91  Ramon Fried          drivers/net(299), net(65)
    433      34  Leo Yu-Chi Liang     arch/riscv(194)
    428      76  Mattijs Korpershoek  drivers/usb(127), boot(68)

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

Yes LLMs can write terrible tests - I have certainly spent many happy
hours arguing with it about tests needing to be specific, etc.
Actually we don't even bother to track code coverage in U-Boot, as
Zephyr does, for example. I have never got around to doing it, but if
we did, it would shine a light on what coverage is missing. My view is
that untested code likely doesn't work - even it if worked when
written (and landed!) it might have been broken later. So we should
have tests. You will be aware that I have expended enormous effort in
expanding tests and I generally build in tests from the start with a
new feature. Also see my review count for test/ above.

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

Yes I fully agree about more testing. Re Labgrid, I basically have my
own u-boot-integration branch [4] which I rebase every now and then
and it works OK. I figured out the first step in redoing it to support
one environment per board, but haven't finished - the key challenge
(apart from scale) is I have ~40 boards on one exporter, not 40
separate rpi exporters each connected to a single board. Perhaps I
will finish it by August. It just needs a solid week of effort. But in
the meantime it works fine as is, on mainline and Concept.

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

Indeed.

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

As an example of automated testing, the core driver model started with
a lot of tests. As we updated and expanded the behaviour, we added
more. We see people updating the behaviour but seldom do we see bugs
in the existing functionality. Same with bootstd (although it took a
while to achieve the same behaviour as the distro scripts), clk,
pmic...still, we have to remind people to add a test when they tweak
the behaviour.

Re getting more reviewers, see my comments above. It has to start with
a successful and pleasant experience when initially sending code.

Thanks again for taking the time to write this up.

Regards,
Simon

>
> Cheers,
> Quentin

[1] https://docs.kernel.org/process/coding-assistants.html
[2] https://lore.kernel.org/u-boot/CAFLszTghO2OM44ZvPg+L2aufKH9ztBz=cCx9sTjNU-eyeS_8AQ@mail.gmail.com/
[3] https://www-concept.deinde.dev/blog/thoughts-on-ai-assisted-coding
[4] https://github.com/sjg20/labgrid/tree/u-boot-integration

Re: U-Boot Concept Tree Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2630 bytes --]

On Fri, Jun 26, 2026 at 08:07:16PM +0200, Quentin Schulz wrote:

[snip]
> 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.

Thanks for the feedback here. I've been staying out of this general
thread as I believe my thoughts are well known already.

For the specific topic here, part of it comes down I believe to a very
uneven level of testing. Both AMD/Xilinx and TI (and in turn, a number
of their vendors) have labs and run tests with a good deal of frequency.
I suspect NXP has some testing going on too, and this isn't an intended
as an exhaustive list. But others really are very much volunteer lead
and getting a reliable and remote lab setup really is a lot of work, so
no one has done it. Rockchip is an unfortunate example here that I know
you run in to. I have an rk3399 I've been trying to find time and space
to get up in the sage lab, for example, but it's still just not there.

Some of this in turn has been held back by a historical lack of a legal
entity for companies to work with that represents the project. We have
part of this solved now, so I am hoping we can make progress in the
future, once we fully finish migrating to community owned
infrastructure. Other parts of it indeed might shake out as part of more
broad usage of at least arm64 platforms in general Linux distributions.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: U-Boot Concept Tree Proposal

[Michal Simek]

On 6/30/26 00:21, Tom Rini wrote:
> On Fri, Jun 26, 2026 at 08:07:16PM +0200, Quentin Schulz wrote:
> 
> [snip]
>> 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.
> 
> Thanks for the feedback here. I've been staying out of this general
> thread as I believe my thoughts are well known already.
> 
> For the specific topic here, part of it comes down I believe to a very
> uneven level of testing. Both AMD/Xilinx and TI (and in turn, a number
> of their vendors) have labs and run tests with a good deal of frequency.
> I suspect NXP has some testing going on too, and this isn't an intended
> as an exhaustive list. But others really are very much volunteer lead
> and getting a reliable and remote lab setup really is a lot of work, so
> no one has done it. Rockchip is an unfortunate example here that I know
> you run in to. I have an rk3399 I've been trying to find time and space
> to get up in the sage lab, for example, but it's still just not there.

This is a topic which we should talk about more.
It is clear that we can't expect that internal labs will join our project
because it is very difficult to provide an access through infrastructure.
Also you can't wait for companies to finish their testing before release.

But on the other hand developers have enough HW on their desks which shouldn't 
be that difficult to share. That's why I think we should provide much easier
way how to share these HW and wire it up with u-boot CI. That could also allow 
to connect custom qemu models instead of just upstream version.

Thanks,
Michal

Re: U-Boot Concept Tree Proposal

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3424 bytes --]

On Wed, Jul 01, 2026 at 10:33:03AM +0200, Michal Simek wrote:
> 
> 
> On 6/30/26 00:21, Tom Rini wrote:
> > On Fri, Jun 26, 2026 at 08:07:16PM +0200, Quentin Schulz wrote:
> > 
> > [snip]
> > > 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.
> > 
> > Thanks for the feedback here. I've been staying out of this general
> > thread as I believe my thoughts are well known already.
> > 
> > For the specific topic here, part of it comes down I believe to a very
> > uneven level of testing. Both AMD/Xilinx and TI (and in turn, a number
> > of their vendors) have labs and run tests with a good deal of frequency.
> > I suspect NXP has some testing going on too, and this isn't an intended
> > as an exhaustive list. But others really are very much volunteer lead
> > and getting a reliable and remote lab setup really is a lot of work, so
> > no one has done it. Rockchip is an unfortunate example here that I know
> > you run in to. I have an rk3399 I've been trying to find time and space
> > to get up in the sage lab, for example, but it's still just not there.
> 
> This is a topic which we should talk about more.
> It is clear that we can't expect that internal labs will join our project
> because it is very difficult to provide an access through infrastructure.
> Also you can't wait for companies to finish their testing before release.
> 
> But on the other hand developers have enough HW on their desks which
> shouldn't be that difficult to share. That's why I think we should provide
> much easier
> way how to share these HW and wire it up with u-boot CI. That could also
> allow to connect custom qemu models instead of just upstream version.

I recently looked at how kernelci handles things currently, and since
it's a "push" service, not a "pull" service, I think there's some
lessons we can learn there, and build on. But that's its own whole
separate topic. One of many that has been delayed by the PLC having to
deal with a number of other issues related to the U-Boot name and
u-boot.org domain.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: U-Boot Concept Tree Proposal

[Peter Robinson]

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.

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

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.

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

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

Regards,
Peter

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

Re: U-Boot Concept Tree Proposal

[Simon Glass]

Hi Peter,

On Fri, 3 Jul 2026 at 11:11, Peter Robinson <pbrobinson@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