at the risk of driving everyone here totally bonkers, i'm going to
take one last shot at explaining what i was thinking of when i first
proposed this whole "maturity level" thing. and, just so you know,
the major reason i'm so cranked up about this is that i'm feeling just
a little territorial -- i was the one who first started nagging people
to consider this idea, so i'm a little edgy when i see folks finally
giving it some serious thought but appearing to get ready to implement
it entirely incorrectly in a way that's going to ruin it irreparably
and make it utterly useless.
this isn't just about defining a single feature called "maturity".
it's about defining a general mechanism so that you can add entirely
new (what i call) "attributes" to kernel features. one attribute
could be "maturity", which could take one of a number of possible
values. another could be "status", with the same restrictions.
heck, you could define the attribute "colour", and decide that various
kernel features could be labelled as (at most) one of "red", "green"
and "chartreuse." that's what i mean by an "attribute", and
attributes would have two critical and non-negotiable properties:
1) they would be entirely orthogonal to one another, and
2) they can be assigned at most one of a pre-defined set of values
that's it. it's really that simple and simon's earlier patch i
think fits that almost perfectly. now, back to the disagreement.
it may be that some people had a different understanding of what was
meant by "maturity" than i did. what *i* meant by that attribute is
a feature's current position in the normal software life cycle, and
that would be one of:
experimental -> normal (stable) -> deprecated -> obsolete
it's a natural progression and, at any point, a feature cannot
possibly have more than one maturity value. it would be as absurd as
saying that someone was a teenager *and* was a twenty-something at the
same time. not possible. and restricting an attribute to a single
value makes definitions and processing *way* easier down the road.
(and note that a feature's maturity says *nothing* about its current
level of quality. that's next.)
another attribute can then be what i was calling "status" but could
also be called "quality". *that* is where you could categorize a
feature as one of FLAKY, BROKEN and so on. that's an entirely
independent categorization from maturity, which means you could have
features that were both experimental and flaky, or deprecated and
broken, or what have you. and those settings would be done with
separate Kconfig directives:
config WHATEVER
maturity DEPRECATED
status BROKEN
from a quick perusal, simon's patch looked pretty much dead-on
(except for that teeth-grinding maturity level of BROKEN :-). but
other than that, it looked good, although i'll have to go back later
and look more closely.
but i hope i've flogged this thoroughly to the point where people
can see what i'm driving at. once you see (as in simon's patch) how
to add the first attribute, it's trivial to simply duplicate that code
to add as many more as you want.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
-
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]
