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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
