Rate of change in the project (Was: Re: xPL Proposal)

Tom Rini trini at konsulko.com
Tue Feb 25 00:23:03 CET 2025


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.

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

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

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

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250224/306e0efb/attachment.sig>


More information about the U-Boot mailing list