Add two new maturity levels of DEPRECATED and OBSOLETE to the kbuild
structure.
Signed-off-by: Robert P. J. Day <[email protected]>
---
one more time, i'll see if i can get this into the main tree, since
previous attempts just seem to disappear into the void, even though
several people seemed to think it was a good idea.
diff --git a/init/Kconfig b/init/Kconfig
index a3f83e2..acc0052 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -29,9 +29,10 @@ config EXPERIMENTAL
<file:Documentation/BUG-HUNTING>, and
<file:Documentation/oops-tracing.txt> in the kernel source).
- This option will also make obsoleted drivers available. These are
- drivers that have been replaced by something else, and/or are
- scheduled to be removed in a future kernel release.
+ At the moment, this option also makes obsolete drivers available,
+ but such drivers really should be removed from the EXPERIMENTAL
+ category and added to either DEPRECATED or OBSOLETE, depending
+ on their status.
Unless you intend to help test and develop a feature or driver that
falls into this category, or you have a situation that requires
@@ -40,6 +41,29 @@ config EXPERIMENTAL
you say Y here, you will be offered the choice of using features or
drivers that are currently considered to be in the alpha-test phase.
+config DEPRECATED
+ bool "Prompt for deprecated code/drivers"
+ default y
+ ---help---
+ Code that is tagged as "deprecated" is officially still available
+ for use but will typically have already been scheduled for removal
+ at some point, so it's in your best interests to start looking for
+ an alternative.
+
+ Check the file Documentation/feature-removal-schedule.txt to see
+ if a particular feature has an official scheduled removal date.
+
+config OBSOLETE
+ bool "Prompt for obsolete code/drivers"
+ default n
+ ---help---
+ Code that is tagged as "obsolete" is officially no longer supported
+ and shouldn't play a part in any normal build, but those features
+ might still be available if you absolutely need access to them.
+
+ You are *strongly* discouraged from continuing to depend on
+ obsolete code on an ongoing, long-term basis.
+
config BROKEN
bool
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
Hi,
Would it be possible to get this patch merged
(or at least DEPRECATED part of it)?
I think that the patch is useful and that the distinction between
DEPRECATED and OBSOLETE options is quite clear:
* DEPRECATED == new better code is available, old code scheduled for removal
* OBSOLETE == no replacement yet but the code is broken by design
and unreliable, not scheduled for removal yet (BTW Robert, I think
CONFIG_OBSOLETE should also be "default y", at least initially)
I would like to start using CONFIG_DEPRECATED and CONFIG_OBSOLETE
for some IDE config config options/features (not drivers) in the future.
Thanks,
Bart
On Sunday 18 February 2007 18:06, Robert P. J. Day wrote:
>
> Add two new maturity levels of DEPRECATED and OBSOLETE to the kbuild
> structure.
>
> Signed-off-by: Robert P. J. Day <[email protected]>
>
> ---
>
> one more time, i'll see if i can get this into the main tree, since
> previous attempts just seem to disappear into the void, even though
> several people seemed to think it was a good idea.
>
> diff --git a/init/Kconfig b/init/Kconfig
> index a3f83e2..acc0052 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -29,9 +29,10 @@ config EXPERIMENTAL
> <file:Documentation/BUG-HUNTING>, and
> <file:Documentation/oops-tracing.txt> in the kernel source).
>
> - This option will also make obsoleted drivers available. These are
> - drivers that have been replaced by something else, and/or are
> - scheduled to be removed in a future kernel release.
> + At the moment, this option also makes obsolete drivers available,
> + but such drivers really should be removed from the EXPERIMENTAL
> + category and added to either DEPRECATED or OBSOLETE, depending
> + on their status.
>
> Unless you intend to help test and develop a feature or driver that
> falls into this category, or you have a situation that requires
> @@ -40,6 +41,29 @@ config EXPERIMENTAL
> you say Y here, you will be offered the choice of using features or
> drivers that are currently considered to be in the alpha-test phase.
>
> +config DEPRECATED
> + bool "Prompt for deprecated code/drivers"
> + default y
> + ---help---
> + Code that is tagged as "deprecated" is officially still available
> + for use but will typically have already been scheduled for removal
> + at some point, so it's in your best interests to start looking for
> + an alternative.
> +
> + Check the file Documentation/feature-removal-schedule.txt to see
> + if a particular feature has an official scheduled removal date.
> +
> +config OBSOLETE
> + bool "Prompt for obsolete code/drivers"
> + default n
> + ---help---
> + Code that is tagged as "obsolete" is officially no longer supported
> + and shouldn't play a part in any normal build, but those features
> + might still be available if you absolutely need access to them.
> +
> + You are *strongly* discouraged from continuing to depend on
> + obsolete code on an ongoing, long-term basis.
> +
> config BROKEN
> bool
On Sun, 18 Feb 2007, Bartlomiej Zolnierkiewicz wrote:
> Hi,
>
> Would it be possible to get this patch merged
> (or at least DEPRECATED part of it)?
>
> I think that the patch is useful and that the distinction between
> DEPRECATED and OBSOLETE options is quite clear:
>
> * DEPRECATED == new better code is available, old code scheduled for removal
>
> * OBSOLETE == no replacement yet but the code is broken by design
> and unreliable, not scheduled for removal yet (BTW Robert, I think
> CONFIG_OBSOLETE should also be "default y", at least initially)
for the most part, that doesn't matter to me one way or the other but,
personally, i'd make obsolete kernel features default to "n". after
all, if someone has gone to the trouble to actually make that config
option *depend* on OBSOLETE, that's a powerful argument that you
should have to work a bit to get it back again. :-)
but i'm good either way.
rday
p.s. for people who missed it the first time, a record of the initial
discussion is here:
http://kerneltrap.org/node/7593
On Sun, 18 Feb 2007 19:35:07 +0100, Bartlomiej Zolnierkiewicz wrote:
> I think that the patch is useful and that the distinction between
> DEPRECATED and OBSOLETE options is quite clear:
>
> * DEPRECATED == new better code is available, old code scheduled for removal
>
> * OBSOLETE == no replacement yet but the code is broken by design
> and unreliable, not scheduled for removal yet
Is that really the consensus on these definitions? I thought it was
more or less the opposite:
* DEPRECATED == no (complete) replacement available yet, but it has
been decided that this code is less than optimal and alternatives
should be preferred
* OBSOLETE == replacement available, no reason to use this code anymore
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)
On Tuesday 20 February 2007 17:27, Tilman Schmidt wrote:
> On Sun, 18 Feb 2007 19:35:07 +0100, Bartlomiej Zolnierkiewicz wrote:
> > I think that the patch is useful and that the distinction between
> > DEPRECATED and OBSOLETE options is quite clear:
> >
> > * DEPRECATED == new better code is available, old code scheduled for removal
> >
> > * OBSOLETE == no replacement yet but the code is broken by design
> > and unreliable, not scheduled for removal yet
>
> Is that really the consensus on these definitions? I thought it was
> more or less the opposite:
>
> * DEPRECATED == no (complete) replacement available yet, but it has
> been decided that this code is less than optimal and alternatives
> should be preferred
>
> * OBSOLETE == replacement available, no reason to use this code anymore
Indeed, this way it makes more sense for me but I'll leave the definitive
answer to a native speaker(s).
Bart
On Tue, 20 Feb 2007, Tilman Schmidt wrote:
> On Sun, 18 Feb 2007 19:35:07 +0100, Bartlomiej Zolnierkiewicz wrote:
> > I think that the patch is useful and that the distinction between
> > DEPRECATED and OBSOLETE options is quite clear:
> >
> > * DEPRECATED == new better code is available, old code scheduled for removal
> >
> > * OBSOLETE == no replacement yet but the code is broken by design
> > and unreliable, not scheduled for removal yet
>
> Is that really the consensus on these definitions? I thought it was
> more or less the opposite:
>
> * DEPRECATED == no (complete) replacement available yet, but it has
> been decided that this code is less than optimal and alternatives
> should be preferred
>
> * OBSOLETE == replacement available, no reason to use this code anymore
those original definitions above are not quite the way i worded it.
please consult the submitted patch to see how i phrased it.
in a nutshell, my idea of deprecated is: perhaps still supported,
still being used, but there is a better alternative available right
now and you should consider switching at your convenience.
obsolete means dead/unsupported/use at own risk. might still work but
no guarantees and could be removed at any time.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
On Tue, 20 Feb 2007, Bartlomiej Zolnierkiewicz wrote:
>
> On Tuesday 20 February 2007 17:27, Tilman Schmidt wrote:
> > Is that really the consensus on these definitions? I thought it was
> > more or less the opposite:
> >
> > * DEPRECATED == no (complete) replacement available yet, but it has
> > been decided that this code is less than optimal and
> > alternatives should be preferred
just to clarify this, that's not my idea of "deprecated".
"deprecated" means that there *is* a complete replacement available
*right now* and you should consider switching to it.
if you can't offer someone a completely functional, better alternative
to what they're using now, then you can't say that what they're using
now is deprecated.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
On Tue, Feb 20, 2007 at 05:47:43PM -0500, Robert P. J. Day wrote:
> On Tue, 20 Feb 2007, Tilman Schmidt wrote:
>
> > On Sun, 18 Feb 2007 19:35:07 +0100, Bartlomiej Zolnierkiewicz wrote:
> > > I think that the patch is useful and that the distinction between
> > > DEPRECATED and OBSOLETE options is quite clear:
> > >
> > > * DEPRECATED == new better code is available, old code scheduled for removal
> > >
> > > * OBSOLETE == no replacement yet but the code is broken by design
> > > and unreliable, not scheduled for removal yet
> >
> > Is that really the consensus on these definitions? I thought it was
> > more or less the opposite:
> >
> > * DEPRECATED == no (complete) replacement available yet, but it has
> > been decided that this code is less than optimal and alternatives
> > should be preferred
> >
> > * OBSOLETE == replacement available, no reason to use this code anymore
>
> those original definitions above are not quite the way i worded it.
> please consult the submitted patch to see how i phrased it.
>
> in a nutshell, my idea of deprecated is: perhaps still supported,
> still being used, but there is a better alternative available right
> now and you should consider switching at your convenience.
>
> obsolete means dead/unsupported/use at own risk. might still work but
> no guarantees and could be removed at any time.
This is also my understanding. In MIB's the terms are sued more-or-less
as defined by Robert.
Sam (non-native)
On Tue, 20 Feb 2007, Sam Ravnborg wrote:
> On Tue, Feb 20, 2007 at 05:47:43PM -0500, Robert P. J. Day wrote:
> > in a nutshell, my idea of deprecated is: perhaps still supported,
> > still being used, but there is a better alternative available right
> > now and you should consider switching at your convenience.
> >
> > obsolete means dead/unsupported/use at own risk. might still work but
> > no guarantees and could be removed at any time.
>
> This is also my understanding. In MIB's the terms are sued more-or-less
> as defined by Robert.
>
> Sam (non-native)
see: http://www.w3.org/TR/WD-html40-970917/convent.html, particularly
how deprecated is defined "outdated by newer constructs," meaning that
there is a better alternative available *now* and not just on the way.
i can always change the wording in the patch, but if we get any more
pedantic, we're going to be counting how many angels you can get on
a split hair.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
Am 20.02.2007 23:52 schrieb Robert P. J. Day:
> "deprecated" means that there *is* a complete replacement available
> *right now* and you should consider switching to it.
>
> if you can't offer someone a completely functional, better alternative
> to what they're using now, then you can't say that what they're using
> now is deprecated.
So, to take a specific example (incidentally the one I am
personally interested in):
isdn4linux (CONFIG_ISDN_I4L), currently marked as "obsolete"
(which is undoubtedly incorrect), would not even qualify as
"deprecated" as long as its successor, the CAPI 2.0 subsystem
(CONFIG_ISDN_CAPI) doesn't support all the hardware currently
supported by old i4l.
Or did I misunderstand something there?
Thanks,
Tilman
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)
On Wed, 21 Feb 2007, Tilman Schmidt wrote:
> Am 20.02.2007 23:52 schrieb Robert P. J. Day:
> > "deprecated" means that there *is* a complete replacement available
> > *right now* and you should consider switching to it.
> >
> > if you can't offer someone a completely functional, better alternative
> > to what they're using now, then you can't say that what they're using
> > now is deprecated.
>
> So, to take a specific example (incidentally the one I am
> personally interested in):
>
> isdn4linux (CONFIG_ISDN_I4L), currently marked as "obsolete"
> (which is undoubtedly incorrect), would not even qualify as
> "deprecated" as long as its successor, the CAPI 2.0 subsystem
> (CONFIG_ISDN_CAPI) doesn't support all the hardware currently
> supported by old i4l.
>
> Or did I misunderstand something there?
IMHO, unless you have a fully-functional replacement ready to go, you
can't call something "deprecated" much less "obsolete". so, yes,
calling isdn4linux "obsolete" is hideously premature.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
On Wed 2007-02-21 00:12:28, Tilman Schmidt wrote:
> Am 20.02.2007 23:52 schrieb Robert P. J. Day:
> > "deprecated" means that there *is* a complete replacement available
> > *right now* and you should consider switching to it.
> >
> > if you can't offer someone a completely functional, better alternative
> > to what they're using now, then you can't say that what they're using
> > now is deprecated.
>
> So, to take a specific example (incidentally the one I am
> personally interested in):
>
> isdn4linux (CONFIG_ISDN_I4L), currently marked as "obsolete"
> (which is undoubtedly incorrect), would not even qualify as
> "deprecated" as long as its successor, the CAPI 2.0 subsystem
> (CONFIG_ISDN_CAPI) doesn't support all the hardware currently
> supported by old i4l.
It probably never will. Some hardware is so obsolete that noone will
care :-).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Am 25.02.2007 11:42 schrieb Pavel Machek:
> On Wed 2007-02-21 00:12:28, Tilman Schmidt wrote:
>> Am 20.02.2007 23:52 schrieb Robert P. J. Day:
>>> "deprecated" means that there *is* a complete replacement available
>>> *right now* and you should consider switching to it.
>>>
>>> if you can't offer someone a completely functional, better alternative
>>> to what they're using now, then you can't say that what they're using
>>> now is deprecated.
>> So, to take a specific example (incidentally the one I am
>> personally interested in):
>>
>> isdn4linux (CONFIG_ISDN_I4L), currently marked as "obsolete"
>> (which is undoubtedly incorrect), would not even qualify as
>> "deprecated" as long as its successor, the CAPI 2.0 subsystem
>> (CONFIG_ISDN_CAPI) doesn't support all the hardware currently
>> supported by old i4l.
>
> It probably never will. Some hardware is so obsolete that noone will
> care :-).
s/supported by/in active use with/
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)