All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: "Robert P. J. Day" <rpjday@mindspring.com>
Cc: Randy Dunlap <rdunlap@xenotime.net>,
	Simon Arlott <simon@fire.lp0.eu>,
	sam@ravnborg.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Stefan Richter <stefanr@s5r6.in-berlin.de>,
	Adrian Bunk <bunk@stusta.de>, Gabriel C <crazy@pimpmylinux.org>,
	netdev@vger.kernel.org
Subject: Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
Date: Fri, 31 Aug 2007 14:06:33 -0400	[thread overview]
Message-ID: <46D858A9.4080506@garzik.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0708311318220.18158@localhost.localdomain>

Robert P. J. Day wrote:
> On Fri, 31 Aug 2007, Randy Dunlap wrote:
> 
>> On Thu, 19 Jul 2007 23:05:57 +0100 Simon Arlott wrote:
>>
>>> On 19/07/07 17:19, Robert P. J. Day wrote:
>>>> On Thu, 19 Jul 2007, Randy Dunlap wrote:
>>>>> I think that Stefan means a patch to the kconfig source code,
>>>>> not the the Kconfig files.  Good luck.  I'd still like to see it.
>>>> yes, i understand what he wanted now.  as a first step (that
>>>> theoretically shouldn't change any behaviour), i'd patch the Kconfig
>>>> structure to add a new attribute ("maturity") which would be allowed
>>>> to be set to *exactly one* of a pre-defined set of values (say,
>>>> OBSOLETE, DEPRECATED, EXPERIMENTAL, and STILLBLEEDING).  and that's
>>>> it, nothing more.
>>>>
>>>> don't try to do anything with any of that just yet, just add the
>>>> infrastructure to support the (optional) association of a maturity
>>>> level with a config option.  that's step one.
>>> What about something like this? I'm not sure if the addition to sym_init
>>> is desirable... I also had to prefix _ to the name for now otherwise it
>>> conflicts badly with the current symbols. It probably should stop
>>> "depends on _BROKEN" etc. too.
> 
> i'm sure i'm going to get shouted down here, but i really disagree
> with "BROKEN" being considered a "maturity level".  IMHO, things like
> EXPERIMENTAL, DEPRECATED and OBSOLETE represent maturity levels, for
> what i think are obvious reasons.
> 
> something like BROKEN, though, has *nothing* to do with maturity.  a
> feature can be any of those maturity levels, and simultaneously be
> BROKEN.  i consider BROKEN to be what i call a "status", and different
> status levels might be the default of normal, or KIND_OF_FLAKY or
> TOTALLY_BORKED -- that's where BROKEN would fit in.

BROKEN is definitely a maturity level.  A more accurate description 
would be BITROTTING perhaps.  The code in question has passed through 
bleeding -> experimental -> stable, and come out the other side.

In contrast, OBSOLETE and DEPRECATED reflect high-level status not code 
quality/maturity.

	Jeff




  reply	other threads:[~2007-08-31 18:07 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-18 20:18 [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus Gabriel C
2007-07-18 20:23 ` Robert P. J. Day
2007-07-18 20:40   ` Randy Dunlap
2007-07-18 20:44     ` Robert P. J. Day
2007-07-18 20:45     ` Jeff Garzik
2007-07-18 20:51       ` Robert P. J. Day
2007-07-18 21:09         ` Adrian Bunk
2007-07-18 21:18           ` Robert P. J. Day
2007-07-19  5:47             ` Adrian Bunk
2007-07-19  7:33               ` Robert P. J. Day
2007-07-19  8:42                 ` Stefan Richter
2007-07-19  9:25                   ` Robert P. J. Day
2007-07-19 13:53                     ` Stefan Richter
2007-07-19 15:31                     ` Randy Dunlap
2007-07-19 16:19                       ` Robert P. J. Day
2007-07-19 22:05                         ` Simon Arlott
2007-07-19 22:28                           ` Robert P. J. Day
2007-08-31 17:25                           ` Randy Dunlap
2007-08-31 17:23                             ` Robert P. J. Day
2007-08-31 18:06                               ` Jeff Garzik [this message]
2007-08-31 19:29                                 ` Jan Engelhardt
2007-08-31 20:16                                 ` Randy Dunlap
2007-08-31 21:00                                   ` Robert P. J. Day
2007-08-31 21:25                                     ` Randy Dunlap
2007-08-31 20:49                                 ` Robert P. J. Day
2007-08-31 22:01                                   ` Jeff Garzik
2007-08-31 22:10                                     ` Robert P. J. Day
2007-09-01 10:44                             ` Robert P. J. Day
2007-09-01 12:49                               ` Sam Ravnborg
2007-09-01 12:56                                 ` Robert P. J. Day
2007-07-18 21:28           ` Robert P. J. Day
2007-07-18 20:52       ` Randy Dunlap
2007-07-18 20:48   ` Gabriel C

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=46D858A9.4080506@garzik.org \
    --to=jeff@garzik.org \
    --cc=bunk@stusta.de \
    --cc=crazy@pimpmylinux.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=rdunlap@xenotime.net \
    --cc=rpjday@mindspring.com \
    --cc=sam@ravnborg.org \
    --cc=simon@fire.lp0.eu \
    --cc=stefanr@s5r6.in-berlin.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.