stefan makes a number of points, all of which i'll add to the wiki page shortly (if i get ambitious enough), but i'll answer them here as well.
On Sat, 28 Apr 2007, Stefan Richter wrote: > Robert P. J. Day wrote: > > http://fsdev.net/wiki/index.php?title=Maturity_levels > > > > rday > > > > A few comments: > > - Your argument should include what the benefits of exposing > DEPRECATED and OBSOLETE as machine-parsable tags are. assuming i understand you correctly, the advantage of adding these attributes is to be able to (de)select, in one operation, anything of that attribute type from your build (in the same way that you can deselect anything EXPERIMENTAL in one mouse click). i think there's a real benefit in being able to say that you can configure and build a kernel that incorporates nothing that people have labelled as obsolete or deprecated (or broken, etc.). (hypothetically, you could do "make allyesconfig", then "make menuconfig" and switch off anything tagged as OBSOLETE, then do your build. that *that* configuration should build would be, IMHO, more important than whether a full build *including* obsolete stuff builds. all that's doing is prioritizing how much you care whether various parts of the kernel actually compile even though, yes, you probably want to eventually fix it up, anyway. but at least you can compile-test the more important features first.) > - "...it's not really experimental but nonetheless claims to be. Bad > craziness all around." > Won't adding more maturity levels increase craziness? not at all. in fact, what it *will* do is prevent those mismatches between some kernel feature visually *advertising* itself as being, say, DEPRECATED, while, in reality, it's *not* tagged that way. or vice versa. there's a lot of that going on in the current Kconfig files as we speak (with EXPERIMENTAL, of course). > All of the levels except BROKEN are highly subjective. i don't think so. we've had this discussion before, and most people seem to agree on what it means for something to be "deprecated" and what it means to be "obsolete." it's not really *that* subjective. > And such tags can and will become outdated. how is that different from what's happening now? there's stuff marked "EXPERIMENTAL" that appears to have been in the kernel for years. and, obviously, the only way a scheme like this is going to work is if developers keep their own subsystems up to date and tag them appropriately. (note also that the beauty of this scheme is that you can start off slowly and, a bit at a time, start tagging stuff with those new attributes. you don't need to do it all at once but, the more you use it, the more rigorous and selective you can make your builds.) > - How is the proposed "maturity" keyword to be used? Will > maturity EXPERIMENTAL > replace > config EXPERIMENTAL > or > depends on EXPERIMENTAL > ? One of your examples for the usage of the keyword, "maturity > OBSOLETE && BROKEN", indicates it is the latter. whoops, good point. it would be used thusly: config FUBAR bool "Grobnit the fubar" maturity DEPRECATED ... in addition, "maturity EXPERIMENTAL" would replace "depends on EXPERIMENTAL", while you would lose the whole "config EXPERIMENTAL" part completely, since EXPERIMENTAL would no longer be a regular "config" option, but a maturity attribute. > - In case it is the latter, didn't you mean by this example "maturity > OBSOLETE | BROKEN" rather than "maturity OBSOLETE && BROKEN"? no, it would make no sense to tag something as maturity OBSOLETE | BROKEN as if there was a choice. any kernel feature would be explicitly tagged as one or more maturity attributes, as in one of, possibly: maturity OBSOLETE maturity BROKEN maturity BROKEN && OBSOLETE && PIECEOFCRAP then, depending on your config selection, you would display *only* those features whose attributes are a *subset* of what you selected: [*] OBSOLETE [ ] BROKEN would display stuff that (in addition to the normal stuff with no maturity tag at all) was OBSOLETE, but *not* OBSOLETE *and* BROKEN, since you clearly did not select BROKEN. > I sometimes voiced my opinion that the Kconfig language and files > should stick to reflect the mere dependencies, while presentation > should be left to the UIs. The "maturity" directive is basically a > variant of "config" or "depends on" with added presentational > information. in a way, yes, it's a variant, but it's a variant that differs enough from a regular "config" and "depends on" that i think trying to mix the two would be a horribly bad idea. i like your suggestion of calling it an "attribute". it's sort of like assigning a type. but the point to note is that this whole idea has a precedent -- EXPERIMENTAL. once you've allowed kernel features to be tagged as EXPERIMENTAL, you're really opened the door to other types of maturity levels that would be just as useful. personally, i don't know how anyone can accept the notion of EXPERIMENTAL, yet resist adding more maturity levels, but that's just me. > Of course everybody is entitled to have a different opinion and ask > for more presentational markup in Kconfig. fair enough, but it's not just presentational markup, in the same way that EXPERIMENTAL isn't *just* presentational markup -- it means more than that. > Something /can/ sensibly be DEPRECATED and OBSOLETE at the same > time. i disagree. in previous exchanges, most people seemed satisfied that those two terms were mutually exclusive. i think the difference in their definitions is self-evident. > (This also means the correct term is not maturity /levels/, but > maturity attributes or the like.) sure, i can go with that, but it's not like it's a critical distinction since only the word "maturity" need appear in the Kconfig file, anyway. rday p.s. a couple more observations. first, rather than mess with EXPERIMENTAL or BROKEN, those can be left entirely alone and a new structure can be added to the parser to support *just* maturity levels of DEPRECATED and OBSOLETE. once that seems to work well, EXPERIMENTAL and BROKEN can be moved over some time in the future but, even without that move, a restricted maturity attribute would still be useful and informative. also, once a few things get tagged, then, as i mentioned before, a full tree build can be done in stages. i recall andrew grumbling that he was still trying to get a full configuration to build. but why try to do it all at once? i'd start with an "allyesconfig" but leaving out all the DEPRECATED, OBSOLETE and BROKEN stuff and beat on that until it worked. then i'd add in the DEPRECATED stuff and do it again. finally, add the OBSOLETE stuff. at each stage, the build might fail but, the further you get into it, the less a build failure should concern you. it's just a thought. -- ======================================================================== 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/
