Mailing List Archive: [PATCH] Introduce two new maturlty levels: DEPRECATED and OBSOLETE.

[PATCH] Introduce two new maturlty levels: DEPRECATED and OBSOLETE.

rpjday at mindspring

Jan 17, 2007, 1:21 PM

Post #1 of 7 (563 views)

To go along with the EXPERIMENTAL kernel config status, introduce
two new states: DEPRECATED and OBSOLETE.

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

---

just adding these config variables to init/Kconfig shouldn't affect
the current build status, but it will allow developers to start to
move over their portions of tree at their convenience.

in particular, features that are truly obsolete should be tagged as
OBSOLETE, as opposed to EXPERIMENTAL.

diff --git a/init/Kconfig b/init/Kconfig
index a3f83e2..f861efd 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,23 @@ 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"
+ ---help---
+ Code that has 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.
+
+config OBSOLETE
+ bool "Prompt for obsolete code/drivers"
+ ---help---
+ Code that has 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.
+
+ It's *strongly* discouraged to continue to depend on obsolete code.
+
config BROKEN
bool

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Introduce two new maturlty levels: DEPRECATED and OBSOLETE. [ In reply to ]

Jan 17, 2007, 1:55 PM

Post #2 of 7 (571 views)

Robert P. J. Day wrote:
> To go along with the EXPERIMENTAL kernel config status, introduce
> two new states: DEPRECATED and OBSOLETE.

I think this is a very good idea. If nothing else, it gives some
middle-of-the-roadness to the continual "to remove or not to remove" debate.

-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Introduce two new maturlty levels: DEPRECATED and OBSOLETE. [ In reply to ]

Jan 17, 2007, 1:56 PM

Post #3 of 7 (552 views)

Robert P. J. Day wrote:
> To go along with the EXPERIMENTAL kernel config status, introduce
> two new states: DEPRECATED and OBSOLETE.
>
> Signed-off-by: Robert P. J. Day <rpjday@mindspring.com>
>
> ---
>
> just adding these config variables to init/Kconfig shouldn't affect
> the current build status, but it will allow developers to start to
> move over their portions of tree at their convenience.
>
> in particular, features that are truly obsolete should be tagged as
> OBSOLETE, as opposed to EXPERIMENTAL.
>
>
> diff --git a/init/Kconfig b/init/Kconfig
> index a3f83e2..f861efd 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,23 @@ 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"
> + ---help---
> + Code that has 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.
> +

DEPRECATED should presumably default to Y; OBSOLETE to n.

-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Introduce two new maturlty levels: DEPRECATED and OBSOLETE. [ In reply to ]

rpjday at mindspring

Jan 17, 2007, 2:05 PM

Post #4 of 7 (551 views)

On Wed, 17 Jan 2007, H. Peter Anvin wrote:

> DEPRECATED should presumably default to Y; OBSOLETE to n.

you presume correctly.

rday
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Introduce two new maturlty levels: DEPRECATED and OBSOLETE. [ In reply to ]

rpjday at mindspring

Jan 17, 2007, 2:07 PM

Post #5 of 7 (567 views)

On Wed, 17 Jan 2007, H. Peter Anvin wrote:

> DEPRECATED should presumably default to Y; OBSOLETE to n.

crap, now i see what you were getting at -- i forgot to assign
defaults. i'll resubmit, but i'll wait for anyone to suggest any
better help content if they have a better idea.

rday
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Introduce two new maturlty levels: DEPRECATED and OBSOLETE. [ In reply to ]

jengelh at linux01

Jan 18, 2007, 2:18 AM

Post #6 of 7 (556 views)

>On Wed, 17 Jan 2007, H. Peter Anvin wrote:
>
>> DEPRECATED should presumably default to Y; OBSOLETE to n.
>
>crap, now i see what you were getting at -- i forgot to assign
>defaults. i'll resubmit, but i'll wait for anyone to suggest any
>better help content if they have a better idea.

Well... _maybe_ documentation/scheduled-removal.txt (or whatever it is
called) could now be merged into the kconfig options and help text. Or
maybe not, to keep it easy to track deprecated code.

Well, even if scheduled-removal.txt stays, you could submit a 2nd patch
putting OBSOLETE and DEPRECATED tags to the Kconfig options listed in
scheduled-removal.txt, so that kconfig+sched are in sync.

-`J'
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Introduce two new maturlty levels: DEPRECATED and OBSOLETE. [ In reply to ]

rpjday at mindspring

Jan 18, 2007, 2:38 AM

Post #7 of 7 (564 views)

On Thu, 18 Jan 2007, Jan Engelhardt wrote:

>
> >On Wed, 17 Jan 2007, H. Peter Anvin wrote:
> >
> >> DEPRECATED should presumably default to Y; OBSOLETE to n.
> >
> >crap, now i see what you were getting at -- i forgot to assign
> >defaults. i'll resubmit, but i'll wait for anyone to suggest any
> >better help content if they have a better idea.
>
> Well... _maybe_ documentation/scheduled-removal.txt (or whatever it
> is called) could now be merged into the kconfig options and help
> text. Or maybe not, to keep it easy to track deprecated code.
>
> Well, even if scheduled-removal.txt stays, you could submit a 2nd
> patch putting OBSOLETE and DEPRECATED tags to the Kconfig options
> listed in scheduled-removal.txt, so that kconfig+sched are in sync.

i'm assuming you mean "Documentation/feature-removal-schedule.txt".
that would *seem* to make sense, after only a few seconds of thought.
once config options are tagged with either DEPRECATED or OBSOLETE,
surely it wouldn't be hard to be able to pull out a list of those from
the source tree, based on their Kconfig dependencies.

but, again, that's getting ahead of ourselves. certainly, it's
something that *could* be done at some point, but not knowing exactly
how one would do that doesn't stop anyone from adding those two config
settings *now*, just to get the process rolling.

let's not over-analyze this too much.

rday

p.s. it might be worth perusing the feature removal file, to see what
features are still listed there even though they were scheduled to be
removed some time ago. just a thought.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/