On Thu, Oct 24, 2024 at 08:18:40AM -0600, Tom Rini wrote: > On Thu, Oct 24, 2024 at 09:26:14AM +0300, Andy Shevchenko wrote: > > On Thu, Oct 24, 2024 at 07:03:24AM +0200, Heinrich Schuchardt wrote: > > > Am 22. Oktober 2024 15:18:45 MESZ schrieb Andy Shevchenko > > > <[email protected]>: > > > >On Tue, Oct 22, 2024 at 08:02:46AM +0200, Heinrich Schuchardt wrote: > > > >> On 10/21/24 16:40, Ilias Apalodimas wrote: > > > >> > On Mon, 21 Oct 2024 at 17:06, Andy Shevchenko > > > >> > <[email protected]> wrote: > > > >> > > > > > >> > > efi_bootmgr_release_uridp_resource() is not used anywhere except > > > >> > > the same file where it is defined. Mark it static. > > > >> > > This helps avoiding the compiler warning: > > > >> > > > > > >> > > lib/efi_loader/efi_bootmgr.c:388:14: warning: no previous > > > >> > > prototype for ‘efi_bootmgr_release_uridp_resource’ > > > >> > > [-Wmissing-prototypes] > > > > > > > >> The function is called efi_bootmgr_release_uridp() since 292a4a4c7b77 > > > >> ("efi_loader: shorten efi_bootmgr_release_uridp_resource()"). > > > > > > > >Thanks! The problem is that U-Boot doesn't have the latest tag (yet) > > > >that includes this change. You can help with managing the conflict. > > > > > > Patches should be based on origin/master (or origin/next once that branch > > > is > > > opened typically after -rc2) and not on tags. > > > > I disagree. The problem with moving target that it's been moving... > > > > The tags are very good to follow and easy to maintain and test and report > > regressions against. What you are suggesting it's like virtually assigning > > tag to very each commit and tell maintainer to cope with this chaos when > > one does something in one "tag" out of 100500 ones and another person in > > another "tag". So, consider tags as stabilisation points, or points of > > stability. Then it's much easier to stick with a few tags that with 100500 > > commits. > > This isn't the linux kernel where there's constant churn. Most of the > time, it doesn't matter at all. Sometimes it does. Then it's a question > of if the custodian wants to do the rebase work themselves, or ask the > submitter to. And since again unlike the kernel almost no one has the > primary job of "work on U-Boot", the threshold for fixup or ask for a > rebase is much lower.
I see your point, thanks for elaboration. Although I think even taking it into account the Linux kernel approach makes some process, which is stable (more or less) and understandable by many. I feel uncomfortable to rebase on top of random commit. I also have scripts to update my branches and the proposed approach breaks this badly. So I prefer to stick with my flow. That said, consider the patch as reported problem by me. I will help testing any new tag that will have a respective fix, or fix separately based on the tag, so I won't need a special commits on top of. -- With Best Regards, Andy Shevchenko
