Re: [PATCH] kbuild: Add the code maturity levels DEPRECATED and OBSOLETE.
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) signature.asc Description: OpenPGP digital signature
Re: [PATCH] kbuild: Add the code maturity levels DEPRECATED and OBSOLETE.
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kbuild: Add the code maturity levels DEPRECATED and OBSOLETE.
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kbuild: Add the code maturity levels DEPRECATED and OBSOLETE.
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) signature.asc Description: OpenPGP digital signature
Re: [PATCH] kbuild: Add the code maturity levels DEPRECATED and OBSOLETE.
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kbuild: Add the code maturity levels DEPRECATED and OBSOLETE.
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kbuild: Add the code maturity levels DEPRECATED and OBSOLETE.
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) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kbuild: Add the code maturity levels DEPRECATED and OBSOLETE.
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kbuild: Add the code maturity levels DEPRECATED and OBSOLETE.
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kbuild: Add the code maturity levels DEPRECATED and OBSOLETE.
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 SchmidtE-Mail: [EMAIL PROTECTED] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
Re: [PATCH] kbuild: Add the code maturity levels DEPRECATED and OBSOLETE.
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kbuild: Add the code maturity levels DEPRECATED and OBSOLETE.
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 > , and > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kbuild: Add the code maturity levels DEPRECATED and OBSOLETE.
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 , and 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
