Re: [RFC PATCH 0/7] scripts: convert remaining Perl utilities in scripts/

[Jonathan Corbet <corbet@lwn.net>]

Breno Rodrigues Alves <breno3011alves@gmail.com> writes:

> Hi Heiko,
>
>> That is an odd reason - if I'm not wrong then you have zero upstream
>> commits, and now are proposing fundamental changes to tools maintained
>> and used by others? I guess this is 100% LLM work(?).
>
> You are right to suspect that I used an LLM as an aid for this series.
> As required by the kernel policy, I will include an Assisted-by: tag in
> every commit to make this fully transparent.

The tag is no longer required, but openness about how you did this work
is. 

> Regarding my lack of upstream history: that is true, I am a new
> contributor. However, I fully understand the code I am submitting. The
> LLM was used to speed up the mechanical translation, but I reviewed every
> line, checked the logic, and tested the scripts' behavior to ensure 1:1
> parity. I am aware that final responsibility for the code is mine.
>
>> So an important part of describing any change is *why* you are doing it.
>> Why are you doing all of these conversions? Some of these scripts have
>> not seen changes in decades and are likely unused; why do we want to
>> mess with them now?
>
> I would like to clarify the motivation behind the conversion, because I
> do not think I presented it convincingly in the cover letter. The goal
> is not simply to "remove Perl", but to reduce the long-term maintenance
> burden.

What is the maintenance burden of scripts that have not been touched in
decades and, perhaps, are not used at all?

To the extent that these scripts *are* maintained, they have maintainers
who understand them; that may no longer be the case after you replace
them.  Who will maintain them going forward?  You can surely understand
that there might be some reluctance to entrust that role to a new
contributor with no track record.

> The kernel already has a clear track record of migrating critical
> tooling to Python (e.g. get_maintainer and checkpatch).

Huh?  You are *trying* to convert those scripts, that certainly has not
been done.  The current maintainer of checkpatch, I believe, was not
enthusiastic about your proposed change.

> Keeping a
> residual set of Perl scripts forces maintainers and contributors to deal
> with two environments and two sets of idioms for the same class of
> tasks. Unifying that code base in Python simplifies review, testing, and
> future contributions. Even scripts that have not changed in decades are
> still part of the tooling ecosystem and may be used by developers;
> removing them from the Perl equation is a consistency gain.

People running them do not care what language they are written in.

> To reduce the risk and demonstrate my commitment, I would like to
> propose a different path: can we start with a single script? I could
> prepare a patch focused only on checkstack.pl (or another script you
> consider a priority), with a detailed justification and a test plan, so
> you can evaluate the process and quality before we consider the rest of
> the series.

You really need to justify such changes beyond "consistency"; the
existing scripts work and the ones that are in active use have at least
some sort of maintenance that you are attempting to sweep aside.

If you want examples, look at the kerneldoc conversion.  There was a
clear reason for that change (it has to integrate with Sphinx, which is
a Python application) and developers who spent several cycles working on
and evaluating the change.  We knew what the maintenance picture would
be going forward.

This work looks more like change for its own sake.

Thanks,

jon