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

[Quentin Schulz <quentin.schulz@cherry.de>]

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

Quentin