ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
To: Jonathan Corbet <corbet@lwn.net>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [TECH TOPIC] Documentation
Date: Thu, 13 Jun 2019 11:57:12 -0300	[thread overview]
Message-ID: <20190613115712.5024a1b2@coco.lan> (raw)
In-Reply-To: <20190612085405.6045d95d@lwn.net>

Em Wed, 12 Jun 2019 08:54:05 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:

> What could be more fun than talking about kernel documentation?

That sounds a topic that we should have some discussion. IMO, the best
would be to put people on some round tables and exchange some ideas
about how we can improve the process. I would try to do it as a
half-day topic, if the agenda would allow, as a standard 50' min
slot doesn't seem to be enough to address the needed things there.

> Things we
> could get into:
> 
>  - The state of the RST transition, what remains to be done, whether it's
>    all just useless churn that makes the documentation worse, etc.

I have a large changeset (with about one patch per Documentation/
dir) with manually written patches with addresses a large amount of
the remaining stuff. I'm hoping to have most of it applied before
KS :-)

There will still be 4 or 5 directories with lots of documentation
files on it, plus ABI and DT. 

>  - Things we'd like to improve in the documentation toolchain.

I remember once I submitted a patch with a script capable of
parsing the files at ABI and produce a parsed content, with the
goal of validating the ABI files against its syntax and to
generate an ABI book.

IMO, it makes sense to have one book containing the Linux ABI, but, 
as the patch didn't have much attention, and I got sidetracked with
something else, I ended giving up on trying to push it. 

Perhaps by KS it would be time to rescue it from some old git tree
and see if it would be worth the time to work on it.

> 
>  - Overall organization of Documentation/ and moving docs when the need
>    arises.  It seems I end up fighting about this more than just about
>    anything else, but I think it's important to organize our docs for the
>    convenience of the people using them.

Fully agreed. It is not always clear where to place some converted
docs.

Also, in the case of driver-specific information, it is not unusual to
have both kernel and user's information at the same file. Ideally, the
best would be to split, but I'm not sure if it would worth the time
for doing such changes.

>  - The ultimate vision for kernel docs (for now).  RST conversion and
>    imposing some organization are important, but they will not,
>    themselves, give us a coherent set of documentation.  What can we do to
>    have documentation that is useful, current, and maintainable, rather
>    than the dusty attic we have now?

Yeah, RST conversion and enforcing an organization of them is important,
as it will enforce a single "coding" style for the documents, but this
is only a small part of the issue.

IMO, we should work to attract people focused on maintaining docs.

I've been doing some userspace maintainership on a few media-related
projects. Among them, I'm maintaining a KDE media player (Kaffeine).

The KDE project has a group of people that it is focused only on
writing documentation, and one group of people per translation language.

IMO, if we want to have a good set of documents, we should have a
group of people working mainly with a "documentation hat", reviewing,
improving and rewriting large chunks of documents.

If we ever have such kind of people working around the Kernel,
I guess the first task would be to imagine what kind of things a new 
Kernel developer needs to know and try to structure a coherent
documentation from that. Such group could use the existing Kernel
printed books as a starting point (perhaps using existing books
documentation that their authors could release them under GPLv2),
and modifying the texts to use what we have nowadays inside the
Kernel's tree.

I guess the main problem is that, for this to work, someone
(possibly a non-profit org) would likely need to sponsor such work,
as this would probably require more time than we could do on our
spare time.

Thanks,
Mauro

  parent reply	other threads:[~2019-06-13 14:57 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-12 14:54 [Ksummit-discuss] [TECH TOPIC] Documentation Jonathan Corbet
2019-06-12 18:22 ` Shuah Khan
2019-06-12 19:12   ` Martin K. Petersen
2019-06-12 19:43     ` Shuah Khan
2019-06-13 14:25   ` Mauro Carvalho Chehab
2019-06-14 21:40     ` Shuah Khan
2019-06-15  0:05       ` Mauro Carvalho Chehab
2019-06-17 10:12         ` Mauro Carvalho Chehab
2019-06-17 17:21           ` Mauro Carvalho Chehab
2019-06-17 18:05             ` [Ksummit-discuss] [PATCH RFC] scripts: add a script to handle Documentation/features Mauro Carvalho Chehab
2019-06-17 18:11               ` Greg Kroah-Hartman
2019-06-17 19:45                 ` Mauro Carvalho Chehab
2019-06-12 20:33 ` [Ksummit-discuss] [TECH TOPIC] Documentation Kate Stewart
2019-06-13 14:17   ` Mauro Carvalho Chehab
2019-06-13 14:57 ` Mauro Carvalho Chehab [this message]
2019-06-13 18:48   ` Greg KH
2019-06-13 19:01     ` Mauro Carvalho Chehab
2019-06-20 18:36 ` Kees Cook
2019-06-20 19:28   ` Jonathan Corbet
2019-07-22 14:52 ` Mauro Carvalho Chehab
2020-06-09 20:53 Jonathan Corbet
2020-06-10  8:49 ` Dan Carpenter
2020-06-11  8:21   ` Daniel Vetter
2020-06-11 14:48 ` Linus Walleij
2020-06-11 18:03   ` Shuah Khan
2020-06-11 18:28     ` Joe Perches
2020-06-11 19:44       ` Shuah Khan
2020-06-12  8:18         ` Laurent Pinchart
2020-06-12  9:19           ` Mike Rapoport
2020-06-12 10:58             ` Mark Brown
2020-06-12 15:48           ` Shuah Khan
2020-06-12  9:07       ` Mike Rapoport
2020-06-12 16:08         ` Shuah Khan
2020-06-13 16:42           ` Julia Lawall
2020-06-13 16:51             ` Joe Perches
2020-06-13 17:04               ` Julia Lawall
2020-06-14 13:23               ` Matthew Wilcox
2020-06-14 14:13                 ` Mike Rapoport
2020-06-15  9:46               ` Jani Nikula
2020-06-18  9:04               ` Mike Rapoport
2020-06-18 14:40                 ` Joe Perches
     [not found]                   ` <20200709122118.0ffaea91@coco.lan>
2020-07-09 11:42                     ` Joe Perches
2020-07-09 12:11                       ` Mike Rapoport
2020-07-09 16:59                         ` Joe Perches
2020-07-09 17:29                           ` Mike Rapoport
2020-07-09 17:57                             ` Andrew Lunn
     [not found]                               ` <104986.1594328429@turing-police>
2020-07-10  0:03                                 ` Joe Perches
2020-06-13 17:05           ` Laurent Pinchart
2020-06-18  9:08 ` Mike Rapoport

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=20190613115712.5024a1b2@coco.lan \
    --to=mchehab+samsung@kernel.org \
    --cc=corbet@lwn.net \
    --cc=ksummit-discuss@lists.linuxfoundation.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).