mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Robert P. J. Day" <rpjday@mindspring.com>
To: Dave Jones <davej@redhat.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: maturity and status and attributes, oh my!
Date: Sat, 1 Sep 2007 04:34:24 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0709010425400.26137@localhost.localdomain> (raw)
In-Reply-To: <20070831230215.GF11499@redhat.com>

On Fri, 31 Aug 2007, Dave Jones wrote:

> On Fri, Aug 31, 2007 at 05:38:34PM -0400, Robert P. J. Day wrote:

> > 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.
>
> Again, not so black and white. It's feasible that something can be
> experimental on one architecture, stable on another (typically x86),
> or even deprecated on x86, but still supported on other
> architectures. It's not just a per arch thing either, in some cases,
> we've had differing levels of maturity based upon other hardware
> constraints, or even varying versions of system software.

absolutely agreed.  but in cases like that, it might just be easier to
not tag that feature *at all*.  nothing in this proposal *forces*
someone to start tagging kernel features in any way.  as you point
out, there may be cases where trying to tag a feature becomes so
hopelessly vague and special-cased, it's easier to just leave it
alone.  but that still doesn't take away from the value of being able
to use this construct elsewhere where its use *is* clear-cut and
unambiguous.

it's like the current use of "EXPERIMENTAL" -- choosing to see
features that are EXPERIMENTAL doesn't change the build process in any
way -- it just affects the choices you're allowed to make.  it doesn't
*force* you to *take* any of those choices.  that's all this new
construct is supposed to do as well.

rday

p.s.  if i read simon's earlier patch correctly, all it's doing right
now is allowing assignment of attributes and values to kernel features
-- it does nothing in terms of being able to use that feature in the
config process.  that would be step two, after this first step is
added and seems to be correct.

-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================

  reply	other threads:[~2007-09-01  8:46 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-31 21:38 Robert P. J. Day
2007-08-31 22:02 ` Jeff Garzik
2007-09-01  6:35   ` Jan Engelhardt
2007-09-01  9:06     ` Robert P. J. Day
2007-08-31 22:36 ` Stefan Richter
2007-09-01  1:23   ` Robert P. J. Day
2007-09-01  9:14     ` Stefan Richter
2007-09-01  9:21       ` Robert P. J. Day
2007-09-01  9:47         ` Stefan Richter
2007-09-01  9:54           ` Robert P. J. Day
2007-09-01 13:14           ` Jan Engelhardt
2007-09-01 13:53             ` Jeff Garzik
2007-09-01 10:43       ` Jeff Garzik
2007-09-01 10:52         ` Robert P. J. Day
2007-09-01 11:06           ` Jeff Garzik
2007-09-01 13:44             ` Bartlomiej Zolnierkiewicz
2007-09-01 13:52               ` Jeff Garzik
2007-09-01 14:27               ` Stefan Richter
     [not found]   ` <Pine.LNX.4.64.0709010435070.26137@localhost.localdomain>
2007-09-01  9:27     ` Stefan Richter
2007-09-01  9:41       ` Robert P. J. Day
2007-09-01 17:22         ` Dave Jones
2007-09-01 17:58           ` Robert P. J. Day
2007-09-01 18:06             ` Robert P. J. Day
2007-09-01 18:24               ` Dave Jones
2007-08-31 23:02 ` Dave Jones
2007-09-01  8:34   ` Robert P. J. Day [this message]
2007-08-31 23:29 Mitchell Erblich
2007-09-01  1:33 ` Robert P. J. Day
2007-09-01  6:39   ` Jan Engelhardt
2007-09-01  7:02     ` Robert P. J. Day

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0709010425400.26137@localhost.localdomain \
    --to=rpjday@mindspring.com \
    --cc=davej@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®