linux-kernel - Re: maturity and status and attributes, oh my!

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0708312109580.7060@localhost.localdomain>
Date:	Fri, 31 Aug 2007 21:23:03 -0400 (EDT)
From:	"Robert P. J. Day" <rpjday@...dspring.com>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: maturity and status and attributes, oh my!

On Sat, 1 Sep 2007, Stefan Richter wrote:

> Robert P. J. Day wrote:
> ...
> > 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
>
> If they are fully orthogonal to another, then they are also
> nonexclusive.  You want them to be mutual exclusive, not orthogonal.

*attributes* would be orthogonal to one another -- the values *within*
an attribute would be mutually exclusive.  maybe i phrased that badly
the first time.  so a feature could have both a maturity *and* a
status (just using my hypothetical attributes here), but no feature
can have an attribute with more than one value.

ergo, you can have a maturity of, say, deprecated, *and* a status of,
say, broken.  is that what you meant?  it's what i was getting at.

> >   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.
>
> Keep in mind though that 'experimental', in the context of Linux
> kernel features, has nothing to do with the age of a feature.

your point is well taken.  i'm just trying to draw a clear distinction
between what i see as the natural chronological progression of a
feature, and its actual level of functionality, which i'm firmly
convinced represent two *very* different pieces of information.
something which is marked as obsolete can still be known to be
functioning perfectly well, while something which is still bleeding
edge might be well known to be broken as well.

with regard to "experimental", what attribute would you imagine it
would be a possible value for, and what other possible values might
that attribute have as opposed to experimental?

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