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