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

Sun Apr 6 23:15:42 CEST 2025

Hi Tom,

On Fri, 4 Apr 2025 at 03:27, Tom Rini <trini at konsulko.com> wrote:
>
> On Thu, Apr 03, 2025 at 12:55:38PM +1300, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 3 Apr 2025 at 11:35, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Thu, Apr 03, 2025 at 08:22:13AM +1300, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Wed, 2 Apr 2025 at 06:18, Tom Rini <trini at konsulko.com> wrote:
> > > > >
> > > > > On Wed, Apr 02, 2025 at 04:45:37AM +1300, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Tue, 1 Apr 2025 at 04:51, Tom Rini <trini at konsulko.com> wrote:
> > > > > > >
> > > > > > > On Fri, Mar 28, 2025 at 11:42:20PM +0000, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Mon, 10 Mar 2025 at 09:53, Tom Rini <trini at konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Fri, Mar 07, 2025 at 08:46:31AM -0600, Tom Rini wrote:
> > > > > > > > > > On Thu, Mar 06, 2025 at 09:10:47AM -0700, Simon Glass wrote:
> > > > > > > > > [snip]
> > > > > > > > > > > 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.
> > > > > > > > > >
> > > > > > > > > > I will take another look at what's still relevant. But I believe it's
> > > > > > > > > > still blocked on the fact that it changes behavior and breaks users.
> > > > > > > > >
> > > > > > > > > In details:
> > > > > > > > >
> > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-2-sjg@chromium.org/
> > > > > > > > >
> > > > > > > > > Now that the underlying BLK problem is resolved, this can just be
> > > > > > > > > dropped I believe. Removing the BLK dependency from BOOTSTD can happen
> > > > > > > > > when you're supporting a flow that lacks a BLK device entirely. This
> > > > > > > > > would be another reminder as to why putting unrelated changes in a
> > > > > > > > > series is a problem.
> > > > > > > >
> > > > > > > > OK, then just don't apply this patch. Problem solved?
> > > > > > >
> > > > > > > Well, for a hypothetical v6 you would not include it, sure.
> > > > > > >
> > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-3-sjg@chromium.org/
> > > > > > > > >
> > > > > > > > > This is fine.
> > > > > > > > >
> > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-4-sjg@chromium.org/
> > > > > > > > >
> > > > > > > > > This is not fine. This is also not a sunxi problem. It means that we
> > > > > > > > > should drop bootmgr from rockchip, where the conversion has already
> > > > > > > > > taken place, and would need to drop it from future conversion too.
> > > > > > > > > Neither of which are desirable changes.
> > > > > > > >
> > > > > > > > Why do you say that? I don't understand how this relates to rockchip
> > > > > > > > or why we would need to drop bootmgr from that.
> > > > > > >
> > > > > > > Then you don't have enough of a grasp of the details of the area you're
> > > > > > > trying to solve problems in? Or maybe you need to refresh yourself on
> > > > > > > the details of the area you're trying to work in.
> > > > > >
> > > > > > Or perhaps there isn't a problem? The sunxi case is special because we
> > > > > > have a FEL boothmeth. That isn't present on rockchip, for example.
> > > > >
> > > > > Again, you seem to have forgotten what the problems with the series
> > > > > were.
> > > >
> > > > No, it's just that we disagree on the path forward.
> > >
> > > Then why did you bring up FEL? That's the part of the migration which is
> > > NOT a problem, I keep being reminded when I ask.
> >
> > FEL needs to get priority, that's all. It was a problem until I
> > adjusted the priority.
>
> And there's been zero objection to this. So why are you mentioning it
> here, in the discussion on why the migration is blocked. I know I had
> been unsure, but I asked, and people answered, and I accepted the
> answer.
>
> > > > > > > > > This patch in particular is
> > > > > > > > > where we have the note:
> > > > > > > > >
> > > > > > > > > "Yes, the introduction of boot standard changed the boot order and
> > > > > > > > > specifically deprioritizing scripts is unexpected."
> > > > > > > > >
> > > > > > > > > Which should have had more attention than it did.
> > > > > > > >
> > > > > > > > From memory the scripts are a fallback used when the other things
> > > > > > > > don't work, so that was the decision I made at the time.
> > > > > > >
> > > > > > > The key point being we changed behavior that others depended on, and
> > > > > > > didn't document it well and didn't make sure the change would work for
> > > > > > > them either.
> > > > > > >
> > > > > > > > > This is the thread that to me spelled out in details where the
> > > > > > > > > conversions are now blocked. We changed behavior and that in turn breaks
> > > > > > > > > users that have come to rely on ordering.
> > > > > > > >
> > > > > > > > I don't know what action to take on that comment. We cannot have 100%
> > > > > > > > backwards compatibility with the scripts, which after all weren't even
> > > > > > > > documented. But it is very close.
> > > > > > >
> > > > > > > You need to get feedback from the people you want to migrate from the
> > > > > > > scripts and ordering and rely on to something else and see what works
> > > > > > > for them.
> > > > > > >
> > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-5-sjg@chromium.org/
> > > > > > > > >
> > > > > > > > > Is an alternative to the above which then turned in to a discussion that
> > > > > > > > > I would very briefly summarize as "no discussions were had between
> > > > > > > > > stakeholders before integrating efi bootmgr with bootstd".
> > > > > > > > >
> > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-6-sjg@chromium.org/
> > > > > > > > >
> > > > > > > > > This is fine, but only relevant once migration happens.
> > > > > > > > >
> > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-7-sjg@chromium.org/
> > > > > > > > >
> > > > > > > > > If Andre is fine with this, this is fine.
> > > > > > > > >
> > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-8-sjg@chromium.org/
> > > > > > > > >
> > > > > > > > > This is a generic bugfix. I will take this to next today.
> > > > > > > > >
> > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-9-sjg@chromium.org/
> > > > > > > > >
> > > > > > > > > If Andre is fine with this, this is fine.
> > > > > > > >
> > > > > > > > Well, is he? I thought he was. Can you check?
> > > > > > >
> > > > > > > You're free to. It's one of the innumerable examples of why when you
> > > > > > > group multiple things in a series and there's problems with another part
> > > > > > > of the series, unrelated changes get dropped.
> > > > > >
> > > > > > It would be easier for me if you could apply the patches as I've suggested.
> > > > > >
> > > > > > But if you are willing to apply these patches and just want me to send
> > > > > > the series again without the BLK and RFC patches, I can do that.
> > > > > > Please let me know either way.
> > > > >
> > > > > Again, you should:
> > > > > - Take the non-bootstd sunxi enhancements, rebase them to next and post
> > > > >   for Andre. By themselves. This way they won't get stuck.
> > > >
> > > > There's no point, though, since it doesn't provide the bootstd migration.
> > >
> > > Are you saying there's no point in generally improving things if it
> > > doesn't also involve one of your particular projects?
> >
> > The series is called 'bootstd: sunxi: Migrate to standard boot'. If
> > you'd like to apply just the patches from that series which don't
> > migrate sunxi to standard boot, please go ahead.
>
> I'm not the sunxi custodian. General sunxi changes would go through that
> tree. And then a repeat of everything I've said about how bundling
> unrelated changes hurts everyone.
>
> > > > > - You should work with Heinrich to come up with something that handles
> > > > >   efi bootmanager and bootstd without breaking how our actual project
> > > > >   users use us.
> > > > >   There's no reason to migrate *more* platforms until we have this
> > > > >   fundamental problem sorted out.
> > > >
> > > > It isn't actually a fundamental problem at all. We shouldn't even be
> > > > discussing this and it is really unfortunate that you continue to
> > > > block this effort.
> > > >
> > > > As to bootmgr, I would be willing to implement a solution here, but it
> > > > would involve changes to how bootmgr works under the hood, i.e. to
> > > > have it be iterative instead of doing everything at the start. My firm
> > > > understanding is that such changes would not be acceptable to
> > > > Ilias/Heinrich and anyway I am unable to get patches into the EFI
> > > > subsystem.
> > > >
> > > > So the fallback is the work-around which Heinrich proposed. He is free
> > > > to implement that if he likes, but I am not planning to do this myself
> > > > as I see it as a short-term measure and it may cause problems for
> > > > bootstd, as did f2bfa0cb1 which I bitterly regret allowing in (but I
> > > > suppose they were happier days before everything froze up).
> > > >
> > > > > - You should work with any FOSS distributions to get their feedback on
> > > > >   what would make their life easier, from a user of U-Boot perspective.
> > > > >   bootstd won't be useful if it's not something our users want to use.
> > > >
> > > > Bootstd is designed to replace the distro scripts and the feedback I
> > > > have received is that it is good at that. If you have any other
> > > > feedback, or any suggestions on people I should contact, I'm happy to
> > > > approach them, or they can email the list and cc me.
> > > >
> > > > But really, it would be a lot easier if you could just apply this
> > > > series so we can move on. If I can see even just a glimmer of
> > > > compromise here it will help my confidence.
> > >
> > > Your sunxi series is broken as posted. I am not interested in applying
> > > or encouraging more bootstd usage until there's actual work being done
> > > to move forward wit bootstd (a thing you want) and EFI (a thing most
> > > distributions want). That would be some of the general feedback you've
> > > been given and missed or forgotten.
> > >
> > > This is even setting aside that I can't recall now if you ever started
> > > on making non-BOOTSTD_FULL more useful / usable in general because it's
> > > so minimal that every conversion ends up also enabling BOOTSTD_FULL in
> > > order to be flexible enough for users to decide SD vs eMMC and so on.
> >
> > You can hold this up for as long as you like, it's your tree.
>
> And you can do whatever you like in your personal tree, sure. But
> there's rules for working in a community project.
>
> > I'm always happy and willing to discuss and commit to future
> > improvements. The pattern I see, well-established now, is that you
> > block my current improvements until some other things are done (this
> > series, PXE and many others). Or sometimes you see my series, come up
> > with a clean-up and block my series until it is based on top of that.
> > If you could move away from that pattern and operate in a more
> > cooperative manner, we could definitely get a lot more done in your
> > tree.
> >
> > But again, you can hold this up as long as you like. I just feel it
> > would be better for the project if you didn't.
>
> I continue to not accept changes from anyone that knowingly break other
> use cases and users. You are not an exception to the rule. Leaving
> things broken for now and improving them later is not an option in
> mainline.

If that is your justification for blocking progress then it won't work
in this case. There is nothing actually broken with my series. Shall I
send it again so you can take another look?

>
> And I ask everyone to fix problems that are exposed when they're doing
> something else. Sometimes, when it comes to Kconfig symbols I'll end up
> doing the cleanup because it's tricky to get things right for 1300
> platforms.

Yes, I know how you feel.

Regards,
Simon