From: Jani Nikula <jani.nikula@linux.intel.com>
To: Akira Yokosawa <akiyks@gmail.com>,
Adam Turner <aaturnerpython@outlook.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>
Subject: Re: Sphinx pre v3 -- removing support
Date: Fri, 03 Jun 2022 22:05:20 +0300 [thread overview]
Message-ID: <87bkv9o9e7.fsf@intel.com> (raw)
In-Reply-To: <4f13e688-1b4c-1a8e-7ca5-b2fc6d21263c@gmail.com>
On Sat, 04 Jun 2022, Akira Yokosawa <akiyks@gmail.com> wrote:
> [+Cc: Mauro]
>
> On Fri, 3 Jun 2022 15:54:33 +0000,
> Adam Turner wrote:
>>>> No releases will be removed from PyPI, but if pre v3 syntax is still
>>>> used, Sphinx 6.0 would fail to properly parse it.
>>
>>> And that's the crux of the problem. From kernel POV I'd very much prefer
>>> not setting an upper bound for the Sphinx version. I think it's
>>> important to be able to build the documentation using the latest Sphinx,
>>> and gradually iron out the inevitable quirks that arise.
>>
>>> However, if you decide to drop support for pre v3 syntax in Sphinx v6,
>>> and we decide to stick to being able to use pre v3 Sphinx, we can't move
>>> forward to newer versions until we bump the lower bound for the Sphinx
>>> version to v3+. (Or we need to hack around Sphinx version differences in
>>> kernel, but I think that would be best avoided.)
>
> I might not be grasping the full context here, but I think the main script of
> kernel documentation tool ./scripts/kernel-doc (a perl script) changes its
> behavior depending on the target Sphinx version.
That doesn't change my opinion that it would be best avoided! ;)
BR,
Jani.
>
> Its help text says:
>
>> Output format modifiers
>
>> reStructuredText only
>
>> -sphinx-version VERSION
>
>> Use the ReST C domain dialect compatible with a specific Sphinx
>
>> Version.
>
>
>>
>> If not specified, kernel-doc will auto-detect using the
>
>> sphinx-build version found on PATH.
>
> So it looks to me like it is already compatible with Sphinx 3.1 and later.
>
>>
>> I don't want to be in the position of knowingly breaking the
>> documentation tooling for the kernel. A strawman of a compromise
>> would be for us (Sphinx) to delay the removal to Sphinx 7.0, and the
>> kernel to increase the minimum to Sphinx 3.1 (required for
>> ".. c:namespace::").
>
> Yes, ".. c:namespace::" is actively used in userspace-api documentation.
>
> FYI, see a recent reply from Mauro WRT support of kernel documentation
> with different versions of Sphinx at:
>
> https://lore.kernel.org/linux-doc/20220521114629.6ee9fc06@coco.lan/
>
> Thanks, Akira
>
>
>> That would enable the kernel to gradually update
>> the syntax over a longer period, as I believe you won't be able to
>> use the v3 syntax currently.
>>
>> Equally, Jonathan said he was hesitant to increase the minimum to
>> Sphinx 3, so perhaps that wouldn't work.
>>
>> A
--
Jani Nikula, Intel Open Source Graphics Center
next prev parent reply other threads:[~2022-06-03 19:06 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-03 14:13 Sphinx pre v3 -- removing support Adam Turner
2022-06-03 14:21 ` Jonathan Corbet
2022-06-03 14:30 ` Adam Turner
2022-06-03 21:34 ` Jonathan Corbet
2022-06-03 15:22 ` Matthew Wilcox
2022-06-03 15:30 ` Adam Turner
2022-06-03 15:38 ` Matthew Wilcox
2022-06-03 15:42 ` Konstantin Ryabitsev
2022-06-03 16:00 ` Jonathan Corbet
2022-06-03 16:26 ` Konstantin Ryabitsev
2022-06-03 21:50 ` Jonathan Corbet
2022-06-13 15:40 ` Konstantin Ryabitsev
2022-06-13 16:00 ` Matthew Wilcox
2022-06-13 16:16 ` Adam Turner
2022-06-13 16:19 ` Matthew Wilcox
2022-06-03 22:11 ` Jonathan Corbet
2022-06-03 15:05 ` Akira Yokosawa
2022-06-03 15:27 ` Adam Turner
2022-06-03 15:44 ` Jani Nikula
2022-06-03 15:54 ` Adam Turner
2022-06-03 16:36 ` Akira Yokosawa
2022-06-03 19:05 ` Jani Nikula [this message]
2022-06-04 8:13 ` Mauro Carvalho Chehab
2022-07-02 11:23 ` Mauro Carvalho Chehab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bkv9o9e7.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=aaturnerpython@outlook.com \
--cc=akiyks@gmail.com \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=mchehab@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).