From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: "Robert P. J. Day" <rpjday@mindspring.com>
Cc: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: random thoughts on DEPRECATED and OBSOLETE
Date: Sun, 29 Apr 2007 00:28:15 +0200 [thread overview]
Message-ID: <4633CA7F.6010505@s5r6.in-berlin.de> (raw)
In-Reply-To: <Pine.LNX.4.64.0704281635190.28274@localhost.localdomain>
Robert P. J. Day wrote:
> On Sat, 28 Apr 2007, Stefan Richter wrote:
>> And that benefit is...? :-)
...
> if you're not convinced, there's nothing else i can think of to say
> that will persuade you.
It didn't come across this way, sorry, but I didn't ask a priori to be
persuaded, but rather because I thought your argument (at the wiki site)
could be enhanced by pointing out the concrete applications of the
facility. When I visited the page, it only explained how the facility
works, not what the end-use is.
[...]
>> But it can be controversial whether a piece of code
>> deserves one of these labels.
>
> in the first place, that would be *entirely* the decision of the
> maintainer, just as it is now. but nothing says that starting to tag
> stuff has to affect you in any way. there should be a top-level
> selection that lets you even *activate* the maturity level settings as
> part of your configuration.
(Although if a certain number of kernel components is inappropriately
labeled, the facility becomes useless of course.)
[...]
>> "maturity" is just like "depends on" with the added feature that UIs
>> are supposed to print the flag onto the screen even if the user did
>> not enable a debug mode of the UI.
>>
>> It's really nothing more.
[...]
> sure, i have no disagreement with that. (um ... was there something
> there i was supposed to address? it just sounded like you were
> clarifying what we were talking about.)
You said "it's not just presentational markup", I said "it is". :-)
[deprecated and obsolete exclusive?]
>> DEPRECATED = "I don't want you to build or run this if you can
>> possibly avoid it."
>>
>> OBSOLETE = "There is other stuff which does more or less the same,
>> and this here could go away in the future."
>
> nope. we've been down this road before, and the consensus was that
> something could be one of deprecated or obsolete, but not both. i can
> re-post those definitions if you want, or you could read about them
> here:
>
> http://kerneltrap.org/node/7593
I see a discussion on OBSOLETE vs. BROKEN there, which even ended in a
consensus, but I do not see an explicit discussion on OBSOLETE vs.
DEPRECATED. The only definition of DEPRECATED I see there is yours, and
as it is worded, it is largely overlapping with the definition of
OBSOLETE (which, as it is laid down in that thread, is mostly yours too)
--- but it is not actually conflicting with it.
Note, another classification system can be found in
Documentation/ABI/README. That one also features the category
"obsolete", but does not include a category "deprecated". This is
beneficial because it doesn't leave room for disagreeing interpretations
like ours, nor for any overlap in the definitions like in those at the
end of the thread you referenced.
--
Stefan Richter
-=====-=-=== -=-- ===--
http://arcgraph.de/sr/
next prev parent reply other threads:[~2007-04-28 22:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-28 13:25 Robert P. J. Day
2007-04-28 16:52 ` Stefan Richter
2007-04-28 18:05 ` Robert P. J. Day
2007-04-28 20:21 ` Stefan Richter
2007-04-28 20:26 ` Stefan Richter
2007-04-28 21:04 ` Robert P. J. Day
2007-04-28 22:28 ` Stefan Richter [this message]
2007-04-28 23:31 ` Robert P. J. Day
2007-04-29 0:29 ` Stefan Richter
2007-04-28 23:38 ` Robert P. J. Day
2007-04-29 0:22 ` Stefan Richter
2007-04-29 6:34 ` Robert P. J. Day
2007-04-28 23:21 ` Tilman Schmidt
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=4633CA7F.6010505@s5r6.in-berlin.de \
--to=stefanr@s5r6.in-berlin.de \
--cc=linux-kernel@vger.kernel.org \
--cc=rpjday@mindspring.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
all inboxes | Powered by JetHome®