From: Akira Yokosawa <akiyks@gmail.com>
To: Adam Turner <aaturnerpython@outlook.com>,
Jani Nikula <jani.nikula@linux.intel.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: Sat, 4 Jun 2022 01:36:04 +0900 [thread overview]
Message-ID: <4f13e688-1b4c-1a8e-7ca5-b2fc6d21263c@gmail.com> (raw)
In-Reply-To: <LO3P123MB26814568842CC74EF831288EC2A19@LO3P123MB2681.GBRP123.PROD.OUTLOOK.COM>
[+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.
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
next prev parent reply other threads:[~2022-06-03 16:36 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 [this message]
2022-06-03 19:05 ` Jani Nikula
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=4f13e688-1b4c-1a8e-7ca5-b2fc6d21263c@gmail.com \
--to=akiyks@gmail.com \
--cc=aaturnerpython@outlook.com \
--cc=corbet@lwn.net \
--cc=jani.nikula@linux.intel.com \
--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).