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: 6155 bytes --]

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

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

-- 
Tom

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