linux-kernel - Re: random thoughts on DEPRECATED and OBSOLETE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0704281919150.29483@localhost.localdomain>
Date:	Sat, 28 Apr 2007 19:31:24 -0400 (EDT)
From:	"Robert P. J. Day" <rpjday@...dspring.com>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
cc:	Linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: random thoughts on DEPRECATED and OBSOLETE

On Sun, 29 Apr 2007, Stefan Richter wrote:

> (Although if a certain number of kernel components is
> inappropriately labeled, the facility becomes useless of course.)

well, sure, but if someone chooses to use a tool incorrectly, there's
really no way to stop them.  and i'm guessing that that sort of thing
would be quickly self-correcting based on peer pressure.  incorrectly
tagged features should become obvious fairly quickly when builds start
to break in unexpected ways.

> You said "it's not just presentational markup", I said "it is". :-)

no, it's not just presentational markup.  it's also a selection or
filtering utility, which i consider distinct from markup.  maybe we're
just disagreeing on semantics, so let's not flog this distinction.

> 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.

in a previous discussion, the definitions were pretty much as follows:

* deprecated:  while a feature is still supported, its use is
discouraged because there is a better alternative that you should
consider migrating to at your convenience.

* obsolete:  while a feature is still in the tree, it is no longer
supported and no one should need it anymore, and everyone *should* be
using the better alternative at this point.

IMHO, there is a clear distinction between those two definitions.
they are not orthogonal, they are mutually exclusive.  put another
way, there is an obvious timeline for features:

  normal -> deprecated -> obsolete

quite simply, based on the above, you can't be deprecated and obsolete
at the same time.

in any event, i don't want to drag this out too much longer.  i think
the proposal is reasonably clear, now it remains to be seen if enough
people think it's worth implementing.

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/