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

[Tom Rini <trini@konsulko.com>]

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

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.

> On Mon, 24 Feb 2025 at 16:23, Tom Rini <trini@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.

> > > On Fri, 21 Feb 2025 at 11:11, Tom Rini <trini@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.

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

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

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

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

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

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

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

-- 
Tom

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