Received-SPF: pass (google.com: domain of linux-kernel+bounces-44742-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
From: Jonathan Corbet <corbet@lwn.net>
To: Jani Nikula <jani.nikula@linux.intel.com>, Breno Leitao
 <leitao@debian.org>, kuba@kernel.org, "David
 S. Miller" <davem@davemloft.net>
Cc: linux-doc@vger.kernel.org, netdev@vger.kernel.org,
 linux-kernel@vger.kernel.org, pabeni@redhat.com, edumazet@google.com
Subject: Re: [PATCH v3] Documentation: Document each netlink family
In-Reply-To: <874jevjgvo.fsf@intel.com>
References: <20231121114831.3033560-1-leitao@debian.org>
 <874jevjgvo.fsf@intel.com>
Date: Tue, 30 Jan 2024 07:22:08 -0700
Message-ID: <87jznqewa7.fsf@meer.lwn.net>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain

Jani Nikula <jani.nikula@linux.intel.com> writes:

> On Tue, 21 Nov 2023, Breno Leitao <leitao@debian.org> wrote:
>> This is a simple script that parses the Netlink YAML spec files
>> (Documentation/netlink/specs/), and generates RST files to be rendered
>> in the Network -> Netlink Specification documentation page.
>
> First of all, my boilerplate complaint: All extra processing for Sphinx
> should really be done using Sphinx extensions instead of adding Makefile
> hacks. I don't think it's sustainable to keep adding this stuff. We
> chose Sphinx because it is extensible, and to avoid the Rube Goldberg
> machine that the previous documentation build system was.

So I feel like we've (me included) have kind of sent Breno around in
circles on this one.  This *was* implemented as an extension once:

  https://lore.kernel.org/netdev/20231103135622.250314-1-leitao@debian.org/

At that time it seemed too complex, and I thought that an external
script would lead to a simpler implementation overall.  Perhaps I was
wrong.

I worry that a proliferation of extensions adds its own sort of
complexity and hazards - look at the things Vegard has fixed recently,
for example.  Relatively few people can work in that environment, and
extensions can make our version-support troubles worse.  So I'm not
fully sold on the idea that everything should be an extension,
especially if it can be expressed as a simple dependency and build step
in the makefile.

Some of the uglier makefile stuff we have is a different story...

Anyway, I apologize for my role in making this particular addition
harder than it needed to be.  Perhaps, for the future, we should put
together and agree on a document (of all things) on how we think this
sort of functionality should be added.

Thanks,

jon