Re: maturity and status and attributes, oh my!

["Robert P. J. Day" <rpjday@mindspring.com>]

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