On Mon, May 26, 2025 at 09:36:03AM +0100, Simon Glass wrote: > -trimming cc > > Hi Tom, > > On Fri, 23 May 2025 at 17:49, Tom Rini <tr...@konsulko.com> wrote: > > > > On Fri, May 23, 2025 at 05:36:52PM +0100, Simon Glass wrote: > > > Hi Heinrich, > > > > > > On Fri, May 23, 2025, 15:19 Heinrich Schuchardt <xypron.g...@gmx.de> > > > wrote: > > > > > > > > On 23.05.25 15:06, Simon Glass wrote: > > > > > Some functions provided in lib/efi_loader are actually useful for the > > > > > app as well. This series refactors the Kconfig and directories a > > > > > little > > > > > so that code is easier to share. > > > > > > > > > > As a starting point, it moves some filename and device-path functions > > > > > to > > > > > the new directory. > > > > > > > > > > The next step would be to move device-path code over, but this will > > > > > need > > > > > some discussion. > > > > > > > > Hello Simon, > > > > > > > > Overall the ideas in this series look fine to me. But this series does > > > > not apply to origin/next. > > > > > > > > Applying: efi_loader: Separate device path into its own header > > > > Patch failed at 0001 efi_loader: Separate device path into its own > > > > header > > > > error: patch failed: cmd/efidebug.c:8 > > > > error: cmd/efidebug.c: patch does not apply > > > > error: patch failed: include/efi_loader.h:967 > > > > error: include/efi_loader.h: patch does not apply > > > > error: patch failed: lib/efi_loader/efi_bootmgr.c:12 > > > > error: lib/efi_loader/efi_bootmgr.c: patch does not apply > > > > error: patch failed: lib/efi_loader/efi_device_path.c:10 > > > > error: lib/efi_loader/efi_device_path.c: patch does not apply > > > > error: patch failed: lib/efi_loader/efi_helper.c:6 > > > > error: lib/efi_loader/efi_helper.c: patch does not apply > > > > > > > > Please, resend the series based on origin/next. > > > > > > > > Patches that are not based on upstream U-Boot cannot be reviewed via > > > > this mailing list. > > > > > > The app is quite behind in Tom's tree due to rejected series. > > > > It was not "Rejected", it was "Changes Requested", please stop > > mis-representing things. > > That seems like a distinction without a difference. For example, [1] > is marked as 'changes requested' but the abuf comment on patch 1 looks > like a rejection to me.
In [1] the requested change is to stop adding abuf everywhere and use the normal malloc/free pattern that is most familiar to everyone. The concept is fine. For the EFI app series, again, I don't know if you're acting in good faith or not, it feels like you aren't. > > > In fact > > > the app is pretty limited on x86 and there is no Arm app at all. > > > > > > My current plan is to move forward and eventually Tom might take it > > > via a pull request. > > > > > > Do you have any other ideas? > > > > > > Perhaps this is something we could put on the agenda for a future call. > > > > There's nothing to discuss in a future call as step one is "post patches > > against mainline". > > Well, you keep bringing it up, so it seems that you are unhappy with > it. An alternative to talking about it, if you prefer, is to accept > the status quo. But either way, it doesn't seem helpful to mention the > same issue on so many threads. I keep bringing up that you keep misbehaving. Maybe you should leave the project if you can't follow the rules everyone else does and people have asked you to stop doing. And this is why I don't want to have more calls with you. We had a call where my understanding was that you would only put stuff in your tree that had been rejected but you felt was unfairly rejected. And that you wouldn't build on top of that because it would be a nightmare. And instead what we have is you've built a heavily divergent downstream tree and want to act like it should get the same community feedback and time that mainline has. Multiple people now have told you they do not want to spend time on your tree. If you want to just do what you want, just fork and rename your project to something else. Hand the domain over to DENX (as they oversee the rest of our resources). But if you want to stay in the community you have to accept that some concepts will be rejected and others need to be reworked a lot. Because at the end of the day, the project needs to work well on the ~1400 different boards it supports, and it needs to be stable while we make changes, slowly. [snip] > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=454989 -- Tom
signature.asc
Description: PGP signature
