Hi Tom, (I changed the subject as 'change' sounds like change for change's sake)
On Mon, 24 Feb 2025 at 16:23, Tom Rini <tr...@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. > > > > > On Fri, 21 Feb 2025 at 11:11, Tom Rini <tr...@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. > > > 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? > > > 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? Does it just need a rebase? Which patches should be included and which not? Also we normally expect patches sent first to have priority. Here you have apparently applied your BLK stuff and then want me to rework on top of it? 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. > 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. > > 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? Regards, Simon