ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Jonathan Corbet <corbet@lwn.net>
To: Markus Heiser <markus.heiser@darmarit.de>,
	Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Jani Nikula <jani.nikula@intel.com>,
	ksummit-discuss@lists.linuxfoundation.org,
	ksummit@lists.linux.dev
Subject: Re: [Ksummit-discuss] [TECH TOPIC] What kernel documentation could be
Date: Mon, 27 Jun 2022 09:27:54 -0600	[thread overview]
Message-ID: <87fsjqyvlx.fsf@meer.lwn.net> (raw)
In-Reply-To: <963dd061-47ba-6f96-72e2-4f34cc952b8c@darmarit.de>

Markus Heiser <markus.heiser@darmarit.de> writes:

> IMO It is unnecessary that the build-chain must run on all
> platforms and with all distributions.
>
> Who observes the Sphinx-doc & docutils development since (>15)
> years is aware that with various (old) Sphinx-doc & docutils
> versions no stable results can be produced, not without
> complicating the build-chain.  And this is exactly the situation
> we are facing today.
>
> The build chain of documentation has nothing to do with kernel
> development (at least in my opinion) and should be decoupled from it:
> maintaining one defined build environment is enough work ... this
> becomes especially clear if you (as Jani recommends) rely more on
> sphinx-modules and widely used tools.

The counterargument to this is that we want as many developers as
possible to be able to build the docs and contribute to them.  We can't
complain that developers have broken the docs build if we don't do what
we can to help them do the build themselves.

One of our longstanding contributors is on Sphinx 1.8.5:

  https://lwn.net/ml/linux-doc/4c403239-3c71-4ab9-2168-f7e9d77008b2%40infradead.org/

I would like to narrow our range of supported versions, but I really
don't want to cut people out.

The real question, perhaps, is whether requiring people to set up a
virtualenv to run a supported version would be too much.  It's something
I worry about.

> Another point on which I now have a clear view are the regular
> expressions: no one likes them (me too), but I can't think of a
> general solution (parser) given the number of requirements for
> parsing source code we have.

I fear you're right.  There are nice C parsers for Python, but they
don't work at the level we need; we need the comments, unexpanded
macros, etc.

That said, the regex expression in kernel-doc is out of hand, with no
documentation, lots of duplication, etc.

> I would like to support the kernel community again, but at the
> moment I have difficulties to follow the many exceptions. I would
> be happy if you keep me in CC .. may be I find my place again
> back in the kernel-doc development :-)

We would be glad to have you back.

Remember that the reason I was hesitant to take your kernel-doc rewrite
at the time was that we were already thrashing too many things and I
wanted to hold at least one piece stable.  Hopefully we're past that
phase now...:)

Thanks,

jon

  reply	other threads:[~2022-06-27 15:27 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-17 20:57 [TECH TOPIC] What kernel documentation could be Jonathan Corbet
2022-06-17 20:57 ` [Ksummit-discuss] " Jonathan Corbet
2022-06-17 21:48 ` Laurent Pinchart
2022-06-17 21:48   ` Laurent Pinchart
2022-06-27 15:18   ` Jonathan Corbet
2022-06-18  8:24 ` Mauro Carvalho Chehab
2022-06-18  8:24   ` Mauro Carvalho Chehab
2022-06-18 11:03   ` Miguel Ojeda
2022-06-18 11:16     ` Mauro Carvalho Chehab
2022-06-18 11:16       ` Mauro Carvalho Chehab
2022-06-18 14:37       ` Miguel Ojeda
2022-06-23  9:18   ` Jani Nikula
2022-06-23  9:57     ` Mauro Carvalho Chehab
2022-06-23 10:30       ` Jani Nikula
2022-06-23 13:40       ` Jonathan Corbet
2022-06-24  7:33         ` Mauro Carvalho Chehab
2022-06-24 16:37           ` Markus Heiser
2022-06-27 15:27             ` Jonathan Corbet [this message]
2022-06-27 15:31               ` Christoph Hellwig
2022-06-28  7:43               ` Mauro Carvalho Chehab
2022-06-28  7:57                 ` Geert Uytterhoeven
2022-06-28 11:01                   ` Mauro Carvalho Chehab
2022-07-02 12:43                     ` Stephen Rothwell
2022-06-24 22:57           ` Jonathan Corbet
2022-06-25  9:10             ` Mauro Carvalho Chehab
2022-06-25 14:00               ` Jonathan Corbet
2022-06-25 18:11                 ` Linus Torvalds
2022-06-26  7:55                   ` Mauro Carvalho Chehab
2022-06-26  9:26                     ` Mauro Carvalho Chehab
2022-06-26  9:53                     ` Mauro Carvalho Chehab
2022-06-27 15:28                       ` Liam Howlett
2022-06-27 15:54                         ` Christian Brauner
2022-06-27 16:27                         ` Mark Brown
2022-06-28 10:53                           ` Mauro Carvalho Chehab
2022-06-28 16:13                         ` Luck, Tony
2022-06-27 15:34                   ` Jonathan Corbet
2022-06-27 17:07                     ` Linus Torvalds
2022-07-02 10:52                   ` Mauro Carvalho Chehab
2022-06-25 17:43 ` Steven Rostedt
2022-06-25 17:48   ` Laurent Pinchart

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=87fsjqyvlx.fsf@meer.lwn.net \
    --to=corbet@lwn.net \
    --cc=jani.nikula@intel.com \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=ksummit@lists.linux.dev \
    --cc=markus.heiser@darmarit.de \
    --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).