Re: random thoughts on DEPRECATED and OBSOLETE

From: Robert P. J. Day
Date: Sat Apr 28 2007 - 19:31:59 EST


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