Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Date:   Thu, 17 Feb 2022 16:32:47 +0100
From:   Tomasz =?UTF-8?B?V2FybmllxYLFgm8=?= <tomasz.warniello@gmail.com>
To:     Jonathan Corbet <corbet@lwn.net>
Cc:     linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] scripts: kernel-doc: Major kernel-doc rework
Message-ID: <20220217163247.03e37c9b@fuji.fritz.box>
In-Reply-To: <8735ki2x62.fsf@meer.lwn.net>
References: <20220205233945.7a4d22d8@fuji.fritz.box>
        <8735ki2x62.fsf@meer.lwn.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Wed, 16 Feb 2022 16:45:25 -0700
Jonathan Corbet <corbet@lwn.net> wrote:

> Some overall thoughts:
> 
>  - Work like this needs to be broken up into digestible batches.  Let's
>    start with the POD stuff that I've (finally) commented on; other
>    stuff can come later.

I will prepare the POD part. As for the rest, you will need a porter if you
decide this is the way to go. I could help with explanations if something is
unclear and as long as the questions come soon. The winter is almost over and
I need to switch to other activities like earning money.

>  - The coding style in the new work is very unkernellike; that will make
>    it harder to get this work merged.

Yes. I can only add a thought: it seems unnatural to me to have the same style
for various languages.

>  - But let's take a step back and ask: why are we doing all of this work
>    in the first place?  What is the benefit to the kernel community from
>    all this churn, and a growth of the kernel-doc script by over 2,000
>    lines (even if an awful lot of them are blank)?

My motivation was just climbing this mountain, nothing else. I don't even
know, how important this script is to whom. I can only guess. Neither am I
a C programmer, nor want to become one. So this question is to another part
of the community.

I could though think of the benefits to the maintainers. In this respect I've
moved things forward quite a bit, I gather.

As for the blank lines, they are just one character each and trivial to get
rid of.

> I'm serious about that last question; do we really want to invest that
> kind of effort into this nasty old script?  Or, if we're going to do
> such a thing, should we maybe start with Markus's rewrite into Python
> instead?  If we're going to thrash the code and make it unrecognizable,
> perhaps we should move to a language that is consistent with the rest of
> the docs build system and which, I believe, is easier for more kernel
> developers to deal with?

I understand. I didn't know there was a rewrite. I'm not into Python, but
if you could post a link, I'd take a look out of curiosity.

If the community prefers Python, what can I say about this? Their choice.

Personally, I'd rather play with translating this script to Raku (aka Perl 6).
I also wonder, how Perl 5 will transition to Perl 7. A question to Perl
experts.

> I am *not* saying that this work cannot be accepted, and I certainly do
> not want to alienate somebody who is actually able to look at kernel-doc
> and not have their eyes bleed out.  But I am saying that, before
> launching into a hundreds-of-patches journey, we should know where we're
> going and why we are doing it.

I agree.

> See what I'm getting at?

Yes. Thanks.

Tomasz