[PATCH] bootstd: Use -c flag with bootdev order

[Simon Glass]

Hi Quentin,

On Mon, 26 May 2025 at 10:09, Quentin Schulz <quentin.schulz at cherry.de> wrote:
>
> Hi Simon,
>
> On 5/26/25 10:35 AM, Simon Glass wrote:
> > Hi Quentin,
> >
> > On Mon, 26 May 2025 at 08:48, Quentin Schulz <quentin.schulz at cherry.de> wrote:
> >>
> >> Hi Simon,
> >>
> >> On 5/24/25 7:42 AM, Simon Glass wrote:
> >>> Update this command to use a -c flag rather than a special 'clear'
> >>> argument.
> >>>
> >>
> >> I don't see the commit which adds the clear command to either master or
> >> next branch, so maybe just fix that in the original commit before
> >> sending a pull request instead of via fixups?
> >
> > Tom rejected that series (or 'changes requested' to be specific). I
> > added it to my tree in merge-request 68:
> >
> > d93f42d6e3d bootstd: Provide a command to select the bootdev order
> >
>
> If changes are required to merge the merge request and considering that
> you are the owner of both the patch being fixed up and the merge
> request, maybe sending a vN+1 instead of fixups would make sense?
> Especially if you haven't sent the "applied" mails like you say below?
>
> I would rather avoid reviewing patches on top of commits that may never
> make it to the main tree.
>
> >>
> >> Did I miss something instead maybe?
> >
> > I didn't send out my 'applied' emails for this series, so it was
> > silently applied to my tree, so far as the mailing list was concerned.
> > Tom wants me to operate my tree silently so I don't always send the
> > emails...
> >
>
> I don't want to pour fuel on the fire but this whole ordeal between you
> and Tom needs to be sorted out, I'm essentially not even looking at any
> of your patches anymore even when I'm in Cc/To. From an outsider PoV,
> the situation is confusing and frustrating. Please do not take this as
> an invitation to include me in the "fights". Nobody likes to see
> arguments lasting months even if they are not part of it. "Fights" may
> sometimes be necessary and healthy for a project but this has become
> anxiety-provoking to me, hence my reluctance to look at any thread you
> both are part of. I also want to be able to again trust that the few
> reviews I occasionally make on the mailing list are useful because they
> are for patches that have a chance of being merged and based on code
> that was merged or soon to be merged (in a maintainer tree with high
> chances of being merged in a subsequent merge request to the main tree).

Thanks for your comments. I fully agree.

Regards,
Simon