Messages in this thread | | | Date | Sat, 28 Apr 2007 19:31:24 -0400 (EDT) | From | "Robert P. J. Day" <> | 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |