Rate of innovation in the project (Was: Re: Rate of change in the project)

[Simon Glass]

Hi Tom,

On Wed, 5 Mar 2025 at 09:22, Tom Rini <trini at konsulko.com> wrote:
>
> On Wed, Mar 05, 2025 at 07:19:25AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, 4 Mar 2025 at 08:29, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Tue, Mar 04, 2025 at 06:13:36AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > (I changed the subject as 'change' sounds like change for change's sake)
> > >
> > > Frankly, you have a lot of "tidy up" patches where nothing was
> > > functionally wrong.
> >
> > Yes, but they are important too. One of the problems I see with U-Boot
> > is that not enough people are willing to do refactoring and code
> > maintenance on the required scale.
>
> Again, how much "refactoring" is needed of everything.

Without regular refactoring, projects just die.

>
> > > > On Mon, 24 Feb 2025 at 16:23, Tom Rini <trini at konsulko.com> wrote:
> > > > >
> > > > > On Sat, Feb 22, 2025 at 05:00:59PM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > (I think you chopped off too much context, so I've added it below)
> > > > >
> > > > > That's fine. But I omitted it because it's also true for any other DM
> > > > > migration, and bootstd more fully and adding more classes of devices for
> > > > > bootmeths and I honestly think you have a half dozen big things that are
> > > > > in various states of being merged and enabled and perhaps even more that
> > > > > didn't get much past sandbox being enabled.
> > > >
> > > > Yes I often have new ideas and start things.
> > >
> > > And my point is they need to be finished.
> >
> > We've been through this quite a bit and I believe we have a shared
> > understanding of why it is hard for me to 'finish' things in your
> > tree.
>
> I don't think we do. Because from my point of view you're as interested
> in finishing up the details and working through the migrations as you
> are on moving to the next thing.

That sounds right, it is nice to finish migrations. But I don't like
the slowness of it all.

>
> > > > > > On Fri, 21 Feb 2025 at 11:11, Tom Rini <trini at konsulko.com> wrote:
> > > > > > >
> > > > > > > On Fri, Feb 21, 2025 at 11:53:20AM -0600, Tom Rini wrote:
> > > > > > > > On Fri, Feb 21, 2025 at 08:03:12AM -0700, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > [snip]
> > > > > >
> > > > > > [unsnip]
> > > > > > > > > > >
> > > > > > > > > > > Sure, but we can't even get sunxi bootstd or LED over the line. How do
> > > > > > > > > > > you imagine we could retire the legacy image?
> > > > > > > > > >
> > > > > > > > > > Partly by focusing on one thing and not 5 things at a time. bootstd is
> > > > > > > > > > stuck on reworking efi bootmanager integration, and LED is waiting for
> > > > > > > > > > someone to confirm that really, finally, we have all of the old use
> > > > > > > > > > cases supported in the new code.
> > > > > > > > > >
> > > > > > > > > > But more importantly, do we really have anyone not using u-boot.img? I
> > > > > > > > > > don't know.
> > > > > > [unsnip end]
> > > > > >
> > > > > > > > > If we did one of these sorts of things at a time, we would only get
> > > > > > > > > 2-3 things done each year!
> > > > > > > >
> > > > > > > > A project with 4 yearly releases finishing two 2-3 big changes a year
> > > > > > > > sounds great to me. Rather than not finishing a dozen things?
> > > > > > >
> > > > > > > As this is a huge thread already, I'm splitting this part out.
> > > > > > >
> > > > > > > I would seriously frame slowing down and having just one big change
> > > > > > > being in progress at a time, until it's done, as a good thing, not a bad
> > > > > > > thing. We're a small community with limited bandwidth.
> > > > > >
> > > > > > I can't see how that would work.
> > > > >
> > > > > Well, what we have today is clearly not working well enough for you. And
> > > > > "just land my changes" is still not an option for mainline.
> > > >
> > > > You really haven't addressed my point here.
> > >
> > > Then I don't see your point, or fundamentally disagree with it.
> >
> > My point is that I am trying to keep U-Boot in a position to solve the
> > major problems I see with boot firmware, largely because I don't see
> > much else out there. I can't do that with 2-3 big changes a year, not
> > even close.
>
> Then maybe you need to fork off and make Simon-Boot. Or maybe you need
> to take leadership of the project as a whole. Because I do not see what
> you want as sustainable for the project.

Or you could just be a little more flexible?

>
> > > > > > I just looked at LED[1] originally sent almost 5 months ago and the
> > > > > > latest version is marked 'changes requested'. I don't know of any
> > > > > > changes I can make. Are you hoping that [sorry forgot who it was] will
> > > > > > get around to digging the only affected device out of his drawer and
> > > > > > try to get the activity-LED going? It might take a while.
> > > > >
> > > > > Yes, and as a reminder it's only been 6 or 7 months since mainline had
> > > > > all of the required functionality, maybe. And what *you* could do to
> > > > > speed things along is implement the functionality on any of the boards
> > > > > at your disposal. Anything with a LED today would be fine for this.
> > > >
> > > > Oh well. I would have thought that Christian's series was enough there?
> > >
> > > Might be. Waiting for someone to have time to confirm functionality.
> > > Which you had previously agreed was a good idea, I thought.
> >
> > OK, so we'll just wait another few releases?
>
> Until someone, which could be you even, has the time to verify things,
> yes. Easily. Happily.

The incentives are wrong here, of course. People should *want* to test
in case patches break their use case. People who wait 6 months to test
are just not that interested in the project.

>
> > > > > > The sunxi one[2] was sent over 6 months ago and the latest version is
> > > > > > also marked 'changes requested'. You could apply that series with
> > > > > > either the bootmgr revert or the patch that drops bootmgr for sunxi.
> > > > > > Then Heinrich can come along with his patch on top of that.
> > > > >
> > > > > The sunxi one is blocked because it needs to be rebased on top of the
> > > > > fix I did for BLK stuff and then yes you also could have done the
> > > > > "bootstd uses bootmanager" idea that you've both agreed is a step in the
> > > > > right direction. Because it's actually a generic issue with bootmgr +
> > > > > bootstd that only became more evident as more platforms moved
> > > > > towards using it.
> > > >
> > > > So can you clearly explain what is blocking sunxi?r
> > >
> > > In no particular order:
> > > - Testing.
> > > - Fixing the problems with efi boot manager, which is a global "use
> > >   bootstd more" problem, not sunxi
> > >
> > > And maybe:
> > > - Handle FEL correctly. I'd have to re-read everything again to see if
> > >   that was resolved right, or not.
> >
> > Andre did the testing which is how he found the bootmgr/FEL problem.
> > FEL is handled correctly in my series.
>
> So FEL is OK afterall, good.
>
> > For bootmgr, there are two patches in my series so you can choose
> > which one you want.
>
> And the answer there was neither, both are wrong. We instead finally hit
> a more fundamental problem. Which you don't want to solve. And Heinrich
> has said he'll post RFC on, but hasn't had time.

Or you could just make a decision.

>
> > > > Does it just need a rebase?
> > >
> > > Not just a rebase.
> > >
> > > > Which patches should be included and which not?
> > >
> > > Once the efi boot manager part is fixed, just the parts required for it?
> >
> > So just take the patch which disables bootmgr from sunxi?
>
> Who was in favour of that idea again?

Andre seemed OK with it as no one uses it at present and it allows us
to make progress.

https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-4-sjg@chromium.org/#3418689

>
> > > > Also we
> > > > normally expect patches sent first to have priority.
> > >
> > > No we don't. There might be some general advice / rules of thumb but
> > > it's far from some sort of absolute rule. Things are merged when they
> > > work and are correct.
> >
> > Well I was a bit put out seeing the series rejected on v3 due to an
> > out-of-tree thing I wasn't aware of.
>
> Yes, you need to figure out how to get a better handle on your emails
> since you shouldn't have been unaware then.

Yes I've scaled back my reviews significantly and that is giving me more time.

>
> > > > Here you have
> > > > apparently applied your BLK stuff and then want me to rework on top of
> > > > it?
> > >
> > > Yes, I applied the "handle BLK correctly" part that I tried to explain
> > > to you how to fix a few times, and you either didn't understand or
> > > didn't care. I'm leaning more towards "didn't care" now and thought we
> > > should break things a little bit first and fix them later.
> > >
> > > > I agreed to the bootmanager work-around but I'm certainly not going to
> > > > write it. I would rather make bootmgr more iterative, if that is
> > > > possible.
> > >
> > > Then more bootstd migrations are likely blocked until it can handle efi
> > > boot manager correctly, which you don't want to do.
> >
> > The correct way to handle bootmgr is (probably?) to have it use
> > bootstd to scan for stuff. But as you know, I can't get patches into
> > the EFI subsystem, so it's moot.
>
> Since you insist on starting with several "tidy up" series that have
> been rejected before starting on the problem at hand, yes, that's true.

Yes, I am aware it is true.

>
> > > > > Which is why I had spent so much time trying to get
> > > > > you to migrate more SoCs to bootstd because it's your feature.
> > > >
> > > > So take the sunxi patches and then I'll do the next one? On the one
> > > > hand you complain that there are too many balls in the air and on the
> > > > other you stop the balls from landing. It just doesn't 'compute' for
> > > > me, sorry.
> > >
> > > Yes, I'm sorry you're having trouble following my requests. Again, I
> > > wanted more bootstd migration not for its own sake, but to expose
> > > problems with the framework and for you to then fix those problems.
> >
> > There is no problem with the framework. Please just follow my notes
> > above and apply the patches. Specifically these ones:
>
> That it doesn't work nicely with EFI boot manager IS a problem with the
> framework.

It's a problem with bootmgr, which I'm not going to take on, since I
am unable to get patches into EFI_LOADER.

>
> > 733876246aa sunxi: Add a bootmeth for FEL
> > ab5fbb4f7c0 efi_loader: bootstd: Drop bootmgr for sunxi
> > (leave this one out for now) 9f4ed60d90c RFC: Revert "bootstd: Make
> > efi_mgr bootmeth work for non-sandbox setups"
> > 90d88509ebd sunxi: Move to bootstd
> > e0a16425620 sunxi: Drop old distro boot variables
> > da69a979ec7 env: Provide a work-around for unquoting fdtfile
> > 7c37601d6be (dm/std-working, dm-public/std-working) sunxi: Move to
> > text environment
> >
> > I'm tired of hearing that there is something wrong with bootstd here,
> > so please stop saying that.
>
> Well, from my point of view there is a problem. Because your "tidy up"
> isn't working with what mainstream OS distributions want. So it's not a
> 1:1 replacement for what we have today that does work.

Which tidy-up?

>
> > > > > So yes, I think things would be in a better place if we tried to get
> > > > > *less* big things done at once and didn't pick up another big thing
> > > > > until the last was really done.
> > > >
> > > > You should address my point above. Are you trying to limit me to 3-4
> > > > large series a year?
> > >
> > > You personally? No. The whole project? Yes, one big feature that's
> > > complete and works every 3 months for a project with limited resources
> > > sounds amazing. U-Boot isn't a toy personal project, it's something used
> > > in production on real devices and needs to move at a sustainable pace
> > > with minimal regressions.
> >
> > I believe that is getting better with the increased focus on testing,
> > something which I have been pushing for years.
>
> I'm referring to the breadth of testing, not the depth of testing. More
> tests are good. More boards being tested is more important. Your lab is
> good, yes, but it's not like HW vendors haven't been testing already and
> for a long time. And your feedback on their feedback (needing to be able
> to use a they-push-out model) wasn't positive.

Are you saying that you want me to implement a framework to access
test results from HW vendors and that until I do that, you consider
that I am holding testing back?? Anyway, don't such frameworks already
exist?

Again, back to this thread, if you want me to migrate things, consider
applying the sunxi patches as I have described above. I will then look
at the next target for bootstd. But while you hold this up, I cannot
move forward with more bootstd migration. It doesn't seem that much to
ask.

- Simon