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