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

["Robert P. J. Day" <rpjday@mindspring.com>]

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/