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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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.

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.

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