On Fri, 31 Aug 2007, Mitchell Erblich wrote: > "Robert P. J. Day" wrote: > > > > 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: > <<< snip>>>> > > > > 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 > > ======================================================================== > Robert Day, > > If I can interpret what you are asking about and changing it abit. > > Don't you think that Maturity can be defined ALSO, as the > number of known bugs and their priority / serverity against a > architecture dependent or independent item? > > Would this suffice and wouldn't it be easier to maintain? > > Mitchell Erblich
perhaps. all i'm begging for is that these attributes be defined cleanly and clearly, and following those two conditions i suggested earlier: 1) all attributes are orthogonal to one another, and 2) values within an attribute are mutually exclusive if you violate either of those conditions, i think you're going to find it very difficult to design sane Kconfig entries around them. if you don't believe me, give it a try. rday p.s. rather than saying that maturity can be defined "also" in another way, you should say that it can be defined "instead" in another way. i don't want to think what it might mean to define something like maturity in two different ways simultaneously, if that's what you were suggesting. that just makes my brain hurt. -- ======================================================================== 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/
