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