[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0707191213130.8844@localhost.localdomain>
Date: Thu, 19 Jul 2007 12:19:19 -0400 (EDT)
From: "Robert P. J. Day" <rpjday@...dspring.com>
To: Randy Dunlap <rdunlap@...otime.net>
cc: Stefan Richter <stefanr@...6.in-berlin.de>,
Adrian Bunk <bunk@...sta.de>, Jeff Garzik <jeff@...zik.org>,
Gabriel C <crazy@...pmylinux.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
netdev@...r.kernel.org
Subject: Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
On Thu, 19 Jul 2007, Randy Dunlap wrote:
> On Thu, 19 Jul 2007 05:25:30 -0400 (EDT) Robert P. J. Day wrote:
>
> > On Thu, 19 Jul 2007, Stefan Richter wrote:
> >
> > > Robert P. J. Day wrote:
> > > > On Thu, 19 Jul 2007, Adrian Bunk wrote:
> > > >
> > > > ...
> > > >> I would consider it more ugly to special case this and that in the
> > > >> kconfig code when plain dependencies already offer exactly the same
> > > >> functionality...
> > > >
> > > > well, this is the *third* time i've proposed adding this kind of
> > > > feature so, at this point, i've really given up caring about it. if
> > > > someone wants to do this, have at it. i have better things to do than
> > > > to keep suggesting it and getting nowhere with it.
> > >
> > > For better or worse, it can often be observed that feature requests
> > > don't set anything in motion until a first patch is sent. Even a
> > > patch that is far from perfect can get things going really quickly.
> > > (If the requested feature makes sense to other people.)
> >
> > i *did* submit a preliminary patch once upon a time, and it
> > (predictably) went nowhere. so, if someone else wants to pick this up
> > and do something with it, you have my blessing. life's too short to
> > keep wasting time on this.
>
> 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.
rday
p.s. and, yes, i really meant it when i said that an option could
have one, and *only* one, maturity level. if you start arguing
this point, i swear, i will hunt you down and give you *such* a
wedgie.
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
-
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/
Powered by blists - more mailing lists