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.
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
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/