From: Jonathan Corbet <corbet@lwn.net>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [CORE TOPIC] Documentation
Date: Mon, 3 Aug 2015 08:33:11 -0600 [thread overview]
Message-ID: <20150803083311.5abd23f6@lwn.net> (raw)
In-Reply-To: <1893963.CjFnBCekyb@vostro.rjw.lan>
On Mon, 03 Aug 2015 15:35:36 +0200
"Rafael J. Wysocki" <rjw@rjwysocki.net> wrote:
> > While I don't discourage it, I am not a fan of automated documentation.
> > As you and mtk would know, writing high quality, informative, systems
> > software documentation is an involved process. And it should be, imo.
> > Same goes for describing APIs and algorithms in code comments. Sure,
> > automation has its pros, particularly keeping docs up to date; yet this
> > does not outweigh a well crafted document, which involves actual though.
>
> "thought" I guess?
>
> I have to say I agree here.
Surely nobody thinks I was saying that the documentation-writing process
can be automated! :) But we go to some lengths now to document our APIs
in the code; I don't think we would want to break that.
> Not to mention the fact that if you are browsing the kernel tree via a web
> frontend or LXR, for example, plain text docs are really good to have.
The nice thing about formats like Markdown or ReST is that they *are*
plain text for all practical purposes. Much better than DocBook in that
regard.
jon
next prev parent reply other threads:[~2015-08-03 14:33 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-01 14:41 [Ksummit-discuss] [CORE TOPIC] Documentation Jonathan Corbet
2015-08-02 7:07 ` Davidlohr Bueso
2015-08-03 13:35 ` Rafael J. Wysocki
2015-08-03 13:27 ` Konstantin Ryabitsev
2015-08-03 14:33 ` Jonathan Corbet [this message]
2015-08-03 20:45 ` Dmitry Torokhov
2015-08-04 10:59 ` Daniel Vetter
2015-08-04 0:52 ` Rafael J. Wysocki
2015-08-04 12:50 ` Laurent Pinchart
2015-08-04 13:03 ` Daniel Vetter
2015-08-04 14:28 ` Laurent Pinchart
2015-08-04 14:30 ` Daniel Vetter
2015-08-04 13:50 ` Dan Carpenter
2015-08-04 14:05 ` Geert Uytterhoeven
2015-08-04 14:29 ` Daniel Vetter
2015-08-04 14:30 ` Laurent Pinchart
2015-08-04 17:10 ` Geert Uytterhoeven
2015-08-04 14:42 ` Konstantin Ryabitsev
2015-08-04 18:21 ` Tim Bird
2015-08-04 21:00 ` Laurent Pinchart
2015-08-04 15:35 ` Mark Brown
2015-08-05 17:07 ` Michael Kerrisk (man-pages)
2015-08-04 17:24 ` Jonathan Corbet
2015-08-04 7:12 ` Michael Ellerman
2015-08-04 7:42 ` Marcel Holtmann
2015-08-04 8:33 ` Peter Huewe
2015-08-05 17:08 ` Michael Kerrisk (man-pages)
2015-08-05 17:19 ` josh
2015-08-05 17:21 ` Konstantin Ryabitsev
2015-08-04 12:54 ` Laurent Pinchart
2015-08-04 13:07 ` Daniel Vetter
2015-08-04 11:09 ` Daniel Vetter
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=20150803083311.5abd23f6@lwn.net \
--to=corbet@lwn.net \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=rjw@rjwysocki.net \
/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.