public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Corbet <corbet@lwn.net>
To: Thorsten Leemhuis <linux@leemhuis.info>, linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, Kees Cook <keescook@chromium.org>,
	Jani Nikula <jani.nikula@linux.intel.com>
Subject: Re: [PATCH v2 0/4] Rewrite the top-level index.rst
Date: Fri, 23 Sep 2022 09:03:36 -0600	[thread overview]
Message-ID: <87r102nnef.fsf@meer.lwn.net> (raw)
In-Reply-To: <aa35d204-3033-96f2-ed83-c5034067fe4b@leemhuis.info>

Thorsten Leemhuis <linux@leemhuis.info> writes:

>>  I maintain that the actual users of our
>> docs are primarily kernel developers.
>
> I guess you are right with that, but maybe that's just like that due to
> the docs we have and not the docs we should have (or should aim for
> having in the long run).
>
> IOW: why is the kernel different from say LibreOffice, Firefox, or some
> random command line app: if I look into the documentation (say because
> I'm using that software for the very first time or because I have a
> problem with it after using it for years) I don't expect to see lots of
> docs at the most prominent place that are only relevant for people that
> want to modify said software; I'd expect things like "what is this
> software and how can I use it", "how can I install this software", "how
> can I report a bug", and "what knobs are available to deal with corner
> cases" there.

For better or for worse, our most prominent user-facing documentation is
the man pages, which are not a part of the kernel repository.  (Hmm...it
wouldn't hurt to add a link to them to the front page, if and when a
site with current man pages exists again).

I don't have that much invested in the current ordering, we can
certainly change it - anytime we want.  Anybody else have an opinion on
that topic?

>> I want to do it because it's a clear step forward and has already been
>> pending for a month.  It is surely not perfect, and there will
>> undoubtedly be changes, perhaps big ones, to come, but I cannot imagine
>> a scenario where we want to go back to the mess we have now.
>
> I understand and yes, maybe it's the right thing to do; but OTOH that
> page is a mess for quite a while already, so is it really a big problem
> to just leave it like that for 9 or 10 more weeks while trying to bring
> in a few more people that might be able to directly bring us on a good
> long-term course?

I guess my feelings are that (1) I've had enough promises to help with
documentation over the years to learn not to count on such until said
help actually materializes, and (2) demonstrating what we can do can, I
hope, only inspire people who know more than me to show what we *really*
can do...

Thanks,

jon

  reply	other threads:[~2022-09-23 15:03 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-22 20:41 [PATCH v2 0/4] Rewrite the top-level index.rst Jonathan Corbet
2022-09-22 20:41 ` [PATCH v2 1/7] docs: promote the title of process/index.html Jonathan Corbet
2022-09-23 17:53   ` David Vernet
2022-09-23 18:31     ` Jonathan Corbet
2022-09-22 20:41 ` [PATCH v2 2/7] docs: Rewrite the front page Jonathan Corbet
2022-09-23 19:02   ` Randy Dunlap
2022-09-23 19:07     ` Jonathan Corbet
2022-09-24  2:05   ` David Vernet
2022-09-22 20:41 ` [PATCH v2 3/7] docs: reconfigure the HTML left column Jonathan Corbet
2022-09-24  2:13   ` David Vernet
2022-09-22 20:41 ` [PATCH v2 4/7] docs: remove some index.rst cruft Jonathan Corbet
2022-09-24  2:14   ` David Vernet
2022-09-22 20:41 ` [PATCH v2 5/7] docs: move asm-annotations.rst into core-api Jonathan Corbet
2022-09-23  7:45   ` Bagas Sanjaya
2022-09-24  2:10   ` kernel test robot
2022-09-24  2:20   ` David Vernet
2022-09-25  3:54   ` Bagas Sanjaya
2022-09-25 21:29     ` Jonathan Corbet
2022-09-22 20:41 ` [PATCH v2 6/7] docs: Expand the front-page CPU-architecture section Jonathan Corbet
2022-09-24  2:25   ` David Vernet
2022-09-25 21:50     ` Jonathan Corbet
2022-09-22 20:41 ` [PATCH v2 7/7] docs: put atomic*.txt and memory-barriers.txt into the core-api book Jonathan Corbet
2022-09-23  4:25   ` Bagas Sanjaya
2022-09-23 13:39     ` Jonathan Corbet
2022-09-25  3:18       ` Bagas Sanjaya
2022-09-25  3:48         ` Randy Dunlap
2022-09-25  3:52           ` Bagas Sanjaya
2022-09-23 18:44   ` Randy Dunlap
2022-09-23 19:06     ` Jonathan Corbet
2022-09-23  8:09 ` [PATCH v2 0/4] Rewrite the top-level index.rst Jani Nikula
2022-09-23  8:55 ` Thorsten Leemhuis
2022-09-23 13:45   ` Jonathan Corbet
2022-09-23 14:43     ` Thorsten Leemhuis
2022-09-23 15:03       ` Jonathan Corbet [this message]
2022-09-23 17:45         ` Kees Cook
2022-09-24  1:56         ` David Vernet
2022-09-23 18:48     ` Randy Dunlap

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=87r102nnef.fsf@meer.lwn.net \
    --to=corbet@lwn.net \
    --cc=jani.nikula@linux.intel.com \
    --cc=keescook@chromium.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@leemhuis.info \
    /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