Re: [PATCH for-4.20] public/version: soften wording for deprecated sub-ops

[Jan Beulich <jbeulich@xxxxxxxx>]

On 06.01.2025 23:01, Stefano Stabellini wrote:
> On Mon, 6 Jan 2025, Jan Beulich wrote:
>> On 06.01.2025 12:08, Andrew Cooper wrote:
>>> On 06/01/2025 11:04 am, Jan Beulich wrote:
>>>> These interfaces were - afaict - originally introduced this way on the
>>>> firm assumption that the used array sizes would be good virtually
>>>> forever.  While this assumption turned out to not be true for at least
>>>> some of them, this still doesn't really render them "broken": They still
>>>> fit their original purpose, and they are still usable for a fair subset
>>>> of environments.  Re-word the comments accordingly.
>>>>
>>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>>
>>> No.
>>>
>>> The community voted and rejected this opinion.
>>
>> That's not my recollection of what was voted on, and with the vote results
>> not being available referring to them is unhelpful anyway.
>>
>> My (admittedly vague) recollection is that it was decided to leave enough
>> room for wording choice by submitters. That would cover your original
>> patch, and it would equally cover mine.
> 
> The community-wide survey indicated that it is acceptable to use the
> term "broken" in our documentation [1]. While the survey was not tied to
> a specific instance, it was undoubtedly influenced by the ongoing
> discussion at the time.

IOW this re-confirms (to me at least) that the vote in itself was ambiguous.
I have no issue at all with the use of the word "broken" in documentation or
code comments, provided this accurately describes the situation. Which it
doesn't here.

> If the purpose of this patch is to replace the term "broken", as it
> would seem from the commit message, I would recommend dropping the patch
> and leaving the wording as it is, given that the community has expressed
> approval of its use. Let us respect that decision.
> 
> However, if the goal is to improve clarity by specifying "due to its
> size limitations" and noting that the truncation occurs "silently", then
> I believe the patch could be reviewed with that objective in mind.
> 
> In other words, we should not replace "broken" simply for the sake of
> doing so. That discussion has already been settled. When reviewing this
> patch, our focus should be on its other merits, if any.
> 
> Based on the above, I would not take the patch in its current form. But
> if Jan is up for rewording the commit message, and focusing purely on
> the clarity of the in-code comments maybe a future version could be
> acceptable.

Assuming the above doesn't change your view, and assuming no-one else is
going to express views in favor of the wording change, I'll consider the
patch rejected. And I'll be once again left with the impression that
things are treated neither equally nor objectively in situations like this
one: To get one's perspective through unaltered one only needs to resist
hard enough to any attempt to find a middle ground. That's not a good
environment to work in, and not something I'd call a "community".

Jan

> [1] 
> https://cryptpad.fr/form/#/2/form/view/7ByH95Vd7KiDOvN4wjV5iUGlMuZbkVdwk7cYpZdluWo/