From: "Michael Kerrisk" <mtk-manpages@gmx.net>
To: Jan Engelhardt <jengelh@computergmbh.de>
Cc: drepper@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: utimensat (man-pages-2.61 is released)
Date: Sun, 08 Jul 2007 12:48:48 +0200 [thread overview]
Message-ID: <20070708104848.238020@gmx.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0707081159530.1536@fbirervta.pbzchgretzou.qr>
> On Jul 8 2007 09:30, Michael Kerrisk wrote:
> >> On Jul 7 2007 18:26, Michael Kerrisk wrote:
> >> >
> >> >I recently released man-pages-2.61.
> >>
> >> utimensat() was introduced in Linux 2.6.22-rc1.
> >
> >Yes, I am aware.
> >
> >> I am kindly hinting that it does not yet have a manpage yet :)
> >
> >Such a hint is a good idea. But strangely, you send it to me,
> >rather than the author of the system call. Why is that?
>
> Related manpages (futimesat(2)) does not list an author.
> So I were to guess who wrote it: you, or Ulrich, or a contributor.
An author of which -- the man page itself, or the system call?
Looking at the source of almost any page in man-pages certainly
shows the author of the page. In the case of the futimesat(2)
man page: yes, I was the author.
So yes, I sometimes write pages for system calls that were
written by others. But this suffers serious limitations:
* Many people are changing the kernel-userland API; leaving me
to write the documentation does not scale well. (To begin
with there is the problem: how can I even tell what has
changed in a new release? But here I must thank Andrew,
who helps a bit by forwarding me things he notices.)
* I am fallible: I sometimes make mistakes of understanding
when interpreting other people's code.
* Even when I do not make mistakes, when I write a man page by
reading someone else's code, all I am doing is interpreting.
The implementation may not match the (code) author's
intention (aka a bug). I may just be accurately documented
buggy behaviour, or accurately describing design mistakes.
(Yes, sometimes I'm smart enough to recognize the bugs and
call them, but that is far from guaranteed.)
Cheers,
Michael
--
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7
Want to help with man page maintenance?
Grab the latest tarball at
http://www.kernel.org/pub/linux/docs/manpages ,
read the HOWTOHELP file and grep the source
files for 'FIXME'.
prev parent reply other threads:[~2007-07-08 10:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-07 16:26 man-pages-2.61 is released Michael Kerrisk
2007-07-07 18:58 ` Jan Engelhardt
2007-07-08 7:30 ` Michael Kerrisk
2007-07-08 10:02 ` utimensat (man-pages-2.61 is released) Jan Engelhardt
2007-07-08 10:48 ` Michael Kerrisk [this message]
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=20070708104848.238020@gmx.net \
--to=mtk-manpages@gmx.net \
--cc=drepper@redhat.com \
--cc=jengelh@computergmbh.de \
--cc=linux-kernel@vger.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