[PATCH] kbuild: Add the code maturity levels DEPRECATED and OBSOLETE.

[PATCH] kbuild: Add the code maturity levels DEPRECATED and OBSOLETE.

[Robert P. J. Day]

  Add two new maturity levels of DEPRECATED and OBSOLETE to the kbuild
structure.

Signed-off-by: Robert P. J. Day <rpjday@mindspring.com>

---

  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
========================================================================

Re: [PATCH] kbuild: Add the code maturity levels DEPRECATED and OBSOLETE.

[Bartlomiej Zolnierkiewicz]

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 <rpjday@mindspring.com>
> 
> ---
> 
>   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

Re: [PATCH] kbuild: Add the code maturity levels DEPRECATED and OBSOLETE.

[Robert P. J. Day]

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

Re: [PATCH] kbuild: Add the code maturity levels DEPRECATED and OBSOLETE.

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 932 bytes --]

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: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [PATCH] kbuild: Add the code maturity levels DEPRECATED and OBSOLETE.

[Bartlomiej Zolnierkiewicz]

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

Re: [PATCH] kbuild: Add the code maturity levels DEPRECATED and OBSOLETE.

[Robert P. J. Day]

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
========================================================================

Re: [PATCH] kbuild: Add the code maturity levels DEPRECATED and OBSOLETE.

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 975 bytes --]

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: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: [PATCH] kbuild: Add the code maturity levels DEPRECATED and OBSOLETE.

[Robert P. J. Day]

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
========================================================================

Re: [PATCH] kbuild: Add the code maturity levels DEPRECATED and OBSOLETE.

[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 :-).
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH] kbuild: Add the code maturity levels DEPRECATED and OBSOLETE.

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]

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: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: [PATCH] kbuild: Add the code maturity levels DEPRECATED and OBSOLETE.

[Robert P. J. Day]

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
========================================================================

Re: [PATCH] kbuild: Add the code maturity levels DEPRECATED and OBSOLETE.

[Sam Ravnborg]

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)

Re: [PATCH] kbuild: Add the code maturity levels DEPRECATED and OBSOLETE.

[Robert P. J. Day]

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
========================================================================