All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.