U-Boot Concept Tree Proposal

Peter Robinson pbrobinson at gmail.com
Thu Jul 9 14:22:30 CEST 2026


Hi Simon,

> > > > > 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.
> > >
> > > Nope, not at all rejecting it, what I was saying is that I don't
> > > believe you have got the community to buy into your idea. I don't see
> > > it as the PLC's job to reject/accept it, as I've always stated it's a
> > > community decision, of which I am but one voice.
> > >
> > > On ideas I believe I have already shared the idea of working branches
> > > for features you believe should be in mainline U-Boot. Outside of that
> > > I don't have other ideas, but it's also not my concept.
> > >
> > > > > 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
> > >
> > > So that gives you a right to hold the domain hostage why?
> > >
> > > Also your past contributions doesn't give you a free pass to force the
> > > landing of patch series that you think should be in there. That's not
> > > how open source works, it's certainly not how this project works.
> > >
> > > I think you need to step back and ask yourself why you're finding it
> > > hard to get patches reviewed and accepted.
> > >
> > > To give you an idea I have had numerous community members complain to
> > > me about you, I am sure Tom has similar, some are to the point where
> > > the only way they will deal with your code is if it's part of the
> > > subsystems they maintain and hence it ends up in their patchwork queue
> > > and otherwise they actively filter mails out from you so they don't
> > > see them. I don't keep a count or details but it's well over 5 and I
> > > may even have to start using something other than fingers.
> > >
> > > To put in straight forward terms, a lot of people are fed up with your
> > > behaviour, then when you get called out for it, or Tom has to have a
> > > conversation with you about it rather than addressing the actual issue
> > > you "take some time out" and come back a few months later without
> > > actually addressing your behaviour.
> > >
> > > Now you're holding the domain hostage which is similar bad behaviour.
> > > Not to even mention that you registered a US U-Boot charity and
> > > attempted to register the trademark all without telling *ANYONE* in
> > > the community what you were doing. Did you think you could just walk
> > > away and keep the project "Because of all your contributions"? Again,
> > > while you have contributed a lot I think the wider community of
> > > contributors as a whole have contributed more, and by contribute I
> > > don't just mean purely on the lines of code, but reviews,
> > > architectural discussions and all sorts of other things that actually
> > > make a community and it gives you no right of ownership over the
> > > project.
> > >
> > > I'm sorry Simon but the way to get your patches reviewed is to rebuild
> > > your standing with the community not by trying to force an official
> > > recognition of a fork by holding the domain hostage.
>
> Reading this I feel that you have imputed all sorts of motives which
> are not there.

Maybe they're not their from you're perspective, but there's a lot of
questions there for you to answer if it's not actually the case.

> > > > 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.
> > >
> > > And as I've stated we can't use it that way, the SFC has requirements
> > > around the project's assets (which include things like domains) as
> > > Neal has explained and I am fairly certain as has the SFC. Also
> > > there's dynamic infrastructure where we need to be able to move things
> > > with little notice so it would cause outages without the control of
> > > the domain.
> > >
> > > > 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.
> > >
> > > As I've stated numerous times before you need to get the community to
> > > buy into this.
> > >
> > > You have kept this "secret" from the community for a very long time,
> > > and by secret you've not been open about your intentions, until we
> > > explicitly asked you to go and explain it to the community.
>
> Well my hope was that we could make some progress and I did take up
> your suggestion. But it seems to have just resulted in creating more
> disagreement. I'm sure that wasn't your intention, but it seems you
> were genuinely surprised by what I wrote.

Because I was somewhat because it wasn't my understanding from what at
least my intentions from my understanding of what you wanted to do.

> I don't want to suggest that I had a clear idea or plan about any of
> this when I set up my tree, other than trying to figure out a way to
> unblock my efforts. But in writing up this Concept idea I thought it
> would add real value to the project. I still recall that you shot down
> standard boot and that was around the beginning of all this.

I'm not sure what "standard boot" means in this context, that term is
used in a number of contexts in early boot firmware. I think of
standard boot as UEFI, there's also you bootstd and a number of other
options. You would have to provide more context.

But I am ultimately allowed to have an opinion, as are you, and
everyone else in the community, some ideas individuals think are good,
some bad, ultimately the community as a whole will generally end up
with the overwhelming opinion that somethings are good and they
ultimately land as a feature in the project, thinks like DM and UEFI I
think are good examples of that, some ideas don't get that backing and
shouldn't land just because they exist in code, and that is also
alright. Ultimately I would hope that an individual takes their ideas
to the community sooner rather than later before the individual does a
large amount of work so as to not invest large amounts of time in
something that the community isn't bought into.

Peter


More information about the U-Boot mailing list