LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Robert P. J. Day" <rpjday@mindspring.com>
To: Valdis.Kletnieks@vt.edu
Cc: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: "obsolete" versus "deprecated", and a new config option?
Date: Wed, 17 Jan 2007 17:04:20 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0701171654480.4298@CPE00045a9c397f-CM001225dbafb6> (raw)
In-Reply-To: <200701172154.l0HLs3BM021024@turing-police.cc.vt.edu>

On Wed, 17 Jan 2007, Valdis.Kletnieks@vt.edu wrote:

> On Wed, 17 Jan 2007 11:51:27 EST, "Robert P. J. Day" said:
> >
> >   in any event, what about introducing a new config variable,
> > OBSOLETE, under "Code maturity level options"?  this would seem to be
> > a quick and dirty way to prune anything that is *supposed* to be
> > obsolete from the build, to make sure you're not picking up dead code
> > by accident.
> >
> >   i think it would be useful to be able to make that kind of
> > distinction since, as the devfs writer pointed out above, the point of
> > labelling something "obsolete" is not to *discourage* someone from
> > using a feature, it's to imply that they *shouldn't* be using that
> > feature.  period.  which suggests there should be an easy, one-step
> > way to enforce that absolutely in a build.
>
> How much of the 'OBSOLETE' code should just be labelled 'BROKEN'
> instead?

the stuff that's actually "broken."  :-)

OBSOLETE is not (or at least *should not* be) equivalent to BROKEN.
"OBSOLETE" should denote code that, while it is no longer supported
and has a viable replacement, may very well still work.  and it may or
may not be slated for removal some day.  there may very well be
reasons to keep "obsolete" code in the kernel, for occasional backward
compatibility, but marking it as "obsolete" is a powerful indicator
that people should *really* try not to use it.

"BROKEN" code, OTOH, really should mean exactly that -- code that is
*known* to be broken.  that would include old code that has suffered
bit rot, but it might also include *new* code that, while it's now
part of the kernel, someone discovers a major flaw in it and no one's
got around to fixing it yet.  so even bleeding-edge code can
technically be "broken" until someone gets around to debugging it.

thoughts?

rday



  reply	other threads:[~2007-01-17 22:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-17 16:51 Robert P. J. Day
2007-01-17 18:13 ` Bill Davidsen
2007-01-17 18:42   ` Robert P. J. Day
2007-01-17 21:54 ` Valdis.Kletnieks
2007-01-17 22:04   ` Robert P. J. Day [this message]
2007-01-17 22:54     ` Valdis.Kletnieks
2007-01-17 22:51       ` Robert P. J. Day
2007-01-18 21:37         ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0701171654480.4298@CPE00045a9c397f-CM001225dbafb6 \
    --to=rpjday@mindspring.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: "obsolete" versus "deprecated", and a new config option?' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).