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

[Simon Glass]

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?

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

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

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

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

Regards,
Simon