Re: [PATCH 1/7] byteorder: replace __u16

[Jan Beulich <jbeulich@xxxxxxxx>]

On 31.10.2024 13:20, Andrew Cooper wrote:
> On 31/10/2024 11:23 am, Jan Beulich wrote:
>> On 16.10.2024 11:37, Jan Beulich wrote:
>>> On 09.10.2024 15:34, Jan Beulich wrote:
>>>> On 09.10.2024 15:20, Andrew Cooper wrote:
>>>>> On 09/10/2024 10:21 am, Jan Beulich wrote:
>>>>>> In {big,little}_endian.h the changes are entirely mechanical, except for
>>>>>> dealing with casting away of const from pointers-to-const on lines
>>>>>> touched anyway.
>>>>>>
>>>>>> In swab.h the casting of constants is done away with as well - I simply
>>>>>> don't see what the respective comment is concerned about in our
>>>>>> environment (sizeof(int) >= 4, sizeof(long) >= {4,8} depending on
>>>>>> architecture, sizeof(long long) >= 8). The comment is certainly relevant
>>>>>> in more general cases. Excess parentheses are dropped as well,
>>>>>> ___swab16()'s local variable is renamed, and __arch__swab16()'s is
>>>>>> dropped as being redundant with ___swab16()'s.
>>>>>>
>>>>>> With that no uses of the type remain, so it moves to linux-compat.h.
>>>>>>
>>>>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>>>>> ---
>>>>>> I'm unconvinced of the need of the separate ___constant_swab16(). I'm
>>>>>> also unconvinced of the need for said constants (that even had casts on
>>>>>> them).
>>>>> There is a still-good series deleting the whole of byteorder/ and
>>>>> replacing it with a few-hundred line single header.
>>>>>
>>>>> It is the second thing stalled on a governance change (prohibited
>>>>> reasons to object to a change) which clearly no-one gives a damn about
>>>>> fixing.  In fact double spite because it denied a good engineer his
>>>>> first changes in Xen.
>>>>>
>>>>>
>>>>> I don't particularly feel like trying to polish byteorder.  I'm inclined
>>>>> to rebase+repost Lin's patches, at which point the majority of this
>>>>> series simply disappears.
>>>> I wouldn't mind you doing so, as long as that other series then progresses.
>>>> What I don't want to get into is the other series being stuck rendering 
>>>> this
>>>> one stuck, too. Then it would imo be better to take this one first, rebase
>>>> the other on top, and work towards it becoming unstuck (whatever that 
>>>> takes;
>>>> I have no recollection of what the issue was back at the time, all I recall
>>>> is that, yes, there was such work at some point).
>>> Just to have a clear picture: Was your reply an objection, with you indeed
>>> meaning me to hold back this tidying work? If so, can you please indicate
>>> when, at least roughly, you mean to re-post what you think wants re-posting?
>>> If not, can you please indicate so, for me to commit stuff that's otherwise
>>> ready to go in (and which that other work should be easy to re-base over)?
>> Just to mention here - short of an answer I'm going to commit this with the
>> R-b from Frediano that I've got.
> 
> nack.

Too late.

> The reason there's even anything to do here is, in part, because you
> were obstructive to Lin's series.
> 
> It wasn't only you, but the maintainers (plural) behaviour on that
> series was so outrageous that it started the effort to governance to
> prohibit certain classes of feedback, to make Xen a less toxic place to
> contribute to.
> 
> I will get to it when I get to it.   You can use the time to reflect on
> how you could have been more helpful in the past, and avoided this whole
> issue.

Do you really think that with this kind of reply you do any better than
what you complain about in my (supposed) earlier behavior? I can't help
the impression that you simply can't live with views differing from your
own in certain cases. If you have specific, reasonably objective comments
on that past communication (which I no longer have to hand), I may
certainly try to do better in the future. Blanket statements like those
above simply aren't actionable (and wording-wise close to a conduct
violation imo).

Jan