On Mon, Jun 22, 2026 at 03:32:21PM +0100, Peter Robinson wrote: > On Thu, 18 Jun 2026 at 16:19, Simon Glass <[email protected]> wrote: > > > > Hi, > > > > On Wed, 3 Jun 2026 at 06:06, Simon Glass <[email protected]> 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+xx...@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
signature.asc
Description: PGP signature
