From: Linus Torvalds <torvalds@linux-foundation.org>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Matt Mackall <mpm@selenic.com>,
randy.dunlap@oracle.com, greg@kroah.com, adobriyan@gmail.com,
remi.colinet@gmail.com, linux-kernel@vger.kernel.org,
linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [RESEND][PATCH] Add /proc/mempool to display mempool usage
Date: Mon, 1 Dec 2008 18:54:30 -0800 (PST) [thread overview]
Message-ID: <alpine.LFD.2.00.0812011843340.3256@nehalem.linux-foundation.org> (raw)
In-Reply-To: <84144f020812011402v3cb3ab24pf5cb6310f2d00c5b@mail.gmail.com>
On Tue, 2 Dec 2008, Pekka Enberg wrote:
>
> OK, but why do we have those different ABI "stages" in
> Documentation/ABI then? The README file there seems to contradict what
> you say. Or maybe I'm reading it wrong...
I think that whole Documentation/ABI stuff is utter tosh, and should just
be thrown out, whenever it talks about interfaces that are _not_ ABI's.
IOW, it's fine to document things that are actually supposed to be stable,
but:
- assuming that non-documentation means that it's not an ABI is bogus
and wrong.
- explicitly documenting something as "not an ABI" is wrongheaded and
stupid, because it's meaningless and only sets people up for being
disappointed later.
So yeah, I think we might as well remove the "testing" one. Right now it
can act in two ways:
- as documentation on how to use it (ie as "stable").
This is fine, but then it shouldn't be called "testing", should it?
- as an excuse for whining later when it _did_ get used, and people break
exported ABI's, and we need to revert the breakage.
And this is the one that I don't think is valid. No amount of
documentation will ever make something less stable.
So as far as I'm concerned, "testing" should either go away (as a way to
discourage people from even _knowing_ about the things, and hoping that
they never get used), or it should be moved to "stable".
And in the end, nothing is ever totally black-and-white or quite that
simple, but that's the mindset you should have.
Finally, when it comes to documentation as a bigger issue:
- wrong documentation is irrelevant. It doesn't matter if the
documentation says "X", when the code does "Y".
If people rely on "Y", then pointing at the docs and saying "but you
should never have relied on it, because teh docs say X" is totally and
utterly bogus. The _documentation_ was wrong. Don't ever use incorrect
documentation as an excuse.
Too many people seem to think that documentation is the "final" argument.
It's not. Not even close. It's a hint and a help, but it's _secondary_ to
code. Anybody who doesn't understand that should never be allowed to write
code (or documentation, for that matte).
[ The same is true of assert()'s in code too - I've seen too many damn
asserts that were simply _wrong_, and then when they triggered, people
would always blindly assume that the assert() was right, and try to
change the code to suit. For some reason people have a hard time asking
themselves whether perhaps the bug was in the assertion itself. ]
Linus
next prev parent reply other threads:[~2008-12-02 2:55 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-29 17:44 Remi Colinet
2008-11-29 21:42 ` Alexey Dobriyan
2008-11-29 23:49 ` Greg KH
2008-11-30 21:00 ` Remi Colinet
2008-12-01 18:12 ` Randy Dunlap
2008-12-01 19:13 ` Matt Mackall
2008-12-01 20:02 ` Andrew Morton
2008-12-01 20:07 ` Pekka Enberg
2008-12-01 20:12 ` Linus Torvalds
2008-12-01 20:23 ` Linus Torvalds
2008-12-01 22:02 ` Pekka Enberg
2008-12-01 22:20 ` Matt Mackall
2008-12-02 2:54 ` Linus Torvalds [this message]
2008-12-04 16:02 ` Michael Kerrisk
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=alpine.LFD.2.00.0812011843340.3256@nehalem.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=greg@kroah.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
--cc=penberg@cs.helsinki.fi \
--cc=randy.dunlap@oracle.com \
--cc=remi.colinet@gmail.com \
/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
Powered by JetHome