linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).