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

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