Re: random thoughts on DEPRECATED and OBSOLETE

["Robert P. J. Day" <rpjday@mindspring.com>]

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/