random thoughts on DEPRECATED and OBSOLETE

random thoughts on DEPRECATED and OBSOLETE

[Robert P. J. Day]

http://fsdev.net/wiki/index.php?title=Maturity_levels

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: random thoughts on DEPRECATED and OBSOLETE

[Stefan Richter]

Robert P. J. Day wrote:
> http://fsdev.net/wiki/index.php?title=Maturity_levels
> 
> rday
> 

A few comments:

  - Your argument should include what the benefits of exposing
    DEPRECATED and OBSOLETE as machine-parsable tags are.

  - "...it's not really experimental but nonetheless claims to be. Bad
    craziness all around."
    Won't adding more maturity levels increase craziness?  All of the
    levels except BROKEN are highly subjective.  And such tags can and
    will become outdated.

  - How is the proposed "maturity" keyword to be used?  Will
        maturity EXPERIMENTAL
    replace
        config EXPERIMENTAL
    or
        depends on EXPERIMENTAL
    ?  One of your examples for the usage of the keyword, "maturity
    OBSOLETE && BROKEN", indicates it is the latter.

  - In case it is the latter, didn't you mean by this example "maturity
    OBSOLETE | BROKEN" rather than "maturity OBSOLETE && BROKEN"?

  - I sometimes voiced my opinion that the Kconfig language and files
    should stick to reflect the mere dependencies, while presentation
    should be left to the UIs.  The "maturity" directive is basically
    a variant of "config" or "depends on" with added presentational
    information.  Of course everybody is entitled to have a different
    opinion and ask for more presentational markup in Kconfig.

  - Something /can/ sensibly be DEPRECATED and OBSOLETE at the same
    time.
    (This also means the correct term is not maturity /levels/, but
    maturity attributes or the like.)
-- 
Stefan Richter
-=====-=-=== -=-- ===--
http://arcgraph.de/sr/

Re: random thoughts on DEPRECATED and OBSOLETE

[Robert P. J. Day]

stefan makes a number of points, all of which i'll add to the wiki
page shortly (if i get ambitious enough), but i'll answer them here as
well.

On Sat, 28 Apr 2007, Stefan Richter wrote:

> Robert P. J. Day wrote:
> > http://fsdev.net/wiki/index.php?title=Maturity_levels
> >
> > rday
> >
>
> A few comments:
>
>   - Your argument should include what the benefits of exposing
>     DEPRECATED and OBSOLETE as machine-parsable tags are.

assuming i understand you correctly, the advantage of adding these
attributes is to be able to (de)select, in one operation, anything of
that attribute type from your build (in the same way that you can
deselect anything EXPERIMENTAL in one mouse click).

i think there's a real benefit in being able to say that you can
configure and build a kernel that incorporates nothing that people
have labelled as obsolete or deprecated (or broken, etc.).

(hypothetically, you could do "make allyesconfig", then "make
menuconfig" and switch off anything tagged as OBSOLETE, then do your
build.  that *that* configuration should build would be, IMHO, more
important than whether a full build *including* obsolete stuff
builds.  all that's doing is prioritizing how much you care whether
various parts of the kernel actually compile even though, yes, you
probably want to eventually fix it up, anyway. but at least you can
compile-test the more important features first.)

>   - "...it's not really experimental but nonetheless claims to be. Bad
>     craziness all around."

>     Won't adding more maturity levels increase craziness?

not at all.  in fact, what it *will* do is prevent those mismatches
between some kernel feature visually *advertising* itself as being,
say, DEPRECATED, while, in reality, it's *not* tagged that way.  or
vice versa.  there's a lot of that going on in the current Kconfig
files as we speak (with EXPERIMENTAL, of course).

> All of the levels except BROKEN are highly subjective.

i don't think so.  we've had this discussion before, and most people
seem to agree on what it means for something to be "deprecated" and
what it means to be "obsolete."  it's not really *that* subjective.

> And such tags can and will become outdated.

how is that different from what's happening now?  there's stuff marked
"EXPERIMENTAL" that appears to have been in the kernel for years.
and, obviously, the only way a scheme like this is going to work is if
developers keep their own subsystems up to date and tag them
appropriately.

(note also that the beauty of this scheme is that you can start off
slowly and, a bit at a time, start tagging stuff with those new
attributes.  you don't need to do it all at once but, the more you use
it, the more rigorous and selective you can make your builds.)

>   - How is the proposed "maturity" keyword to be used?  Will
>         maturity EXPERIMENTAL
>     replace
>         config EXPERIMENTAL
>     or
>         depends on EXPERIMENTAL
>     ?  One of your examples for the usage of the keyword, "maturity
>     OBSOLETE && BROKEN", indicates it is the latter.

whoops, good point.  it would be used thusly:

config FUBAR
	bool "Grobnit the fubar"
	maturity DEPRECATED
	...

in addition, "maturity EXPERIMENTAL" would replace "depends on
EXPERIMENTAL", while you would lose the whole "config EXPERIMENTAL"
part completely, since EXPERIMENTAL would no longer be a regular
"config" option, but a maturity attribute.

>   - In case it is the latter, didn't you mean by this example "maturity
>     OBSOLETE | BROKEN" rather than "maturity OBSOLETE && BROKEN"?

no, it would make no sense to tag something as

	maturity OBSOLETE | BROKEN

as if there was a choice.  any kernel feature would be explicitly
tagged as one or more maturity attributes, as in one of, possibly:

	maturity OBSOLETE
	maturity BROKEN
	maturity BROKEN && OBSOLETE && PIECEOFCRAP

then, depending on your config selection, you would display *only*
those features whose attributes are a *subset* of what you selected:

	[*] OBSOLETE
	[ ] BROKEN

would display stuff that (in addition to the normal stuff with no
maturity tag at all) was OBSOLETE, but *not* OBSOLETE *and* BROKEN,
since you clearly did not select BROKEN.

> I sometimes voiced my opinion that the Kconfig language and files
> should stick to reflect the mere dependencies, while presentation
> should be left to the UIs.  The "maturity" directive is basically a
> variant of "config" or "depends on" with added presentational
> information.

in a way, yes, it's a variant, but it's a variant that differs enough
from a regular "config" and "depends on" that i think trying to mix
the two would be a horribly bad idea.

i like your suggestion of calling it an "attribute".  it's sort of
like assigning a type.  but the point to note is that this whole idea
has a precedent -- EXPERIMENTAL.  once you've allowed kernel features
to be tagged as EXPERIMENTAL, you're really opened the door to other
types of maturity levels that would be just as useful.  personally, i
don't know how anyone can accept the notion of EXPERIMENTAL, yet
resist adding more maturity levels, but that's just me.

> Of course everybody is entitled to have a different opinion and ask
> for more presentational markup in Kconfig.

fair enough, but it's not just presentational markup, in the same way
that EXPERIMENTAL isn't *just* presentational markup -- it means more
than that.

> Something /can/ sensibly be DEPRECATED and OBSOLETE at the same
> time.

i disagree.  in previous exchanges, most people seemed satisfied that
those two terms were mutually exclusive.  i think the difference in
their definitions is self-evident.

> (This also means the correct term is not maturity /levels/, but
> maturity attributes or the like.)

sure, i can go with that, but it's not like it's a critical
distinction since only the word "maturity" need appear in the Kconfig
file, anyway.

rday

p.s.  a couple more observations.  first, rather than mess with
EXPERIMENTAL or BROKEN, those can be left entirely alone and a new
structure can be added to the parser to support *just* maturity levels
of DEPRECATED and OBSOLETE.  once that seems to work well,
EXPERIMENTAL and BROKEN can be moved over some time in the future but,
even without that move, a restricted maturity attribute would still be
useful and informative.

also, once a few things get tagged, then, as i mentioned before, a
full tree build can be done in stages.  i recall andrew grumbling that
he was still trying to get a full configuration to build.  but why try
to do it all at once?

i'd start with an "allyesconfig" but leaving out all the DEPRECATED,
OBSOLETE and BROKEN stuff and beat on that until it worked.  then i'd
add in the DEPRECATED stuff and do it again.  finally, add the
OBSOLETE stuff.  at each stage, the build might fail but, the further
you get into it, the less a build failure should concern you.

it's just a thought.

-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: random thoughts on DEPRECATED and OBSOLETE

[Stefan Richter]

Robert P. J. Day wrote:
> On Sat, 28 Apr 2007, Stefan Richter wrote:
>> Robert P. J. Day wrote:
>>> http://fsdev.net/wiki/index.php?title=Maturity_levels
...
>>   - Your argument should include what the benefits of exposing
>>     DEPRECATED and OBSOLETE as machine-parsable tags are.

(I said that because most things go in because they have uses, not just
because we can.)

> assuming i understand you correctly, the advantage of adding these
> attributes is to be able to (de)select, in one operation, anything of
> that attribute type from your build (in the same way that you can
> deselect anything EXPERIMENTAL in one mouse click).
> 
> i think there's a real benefit in being able to say that you can
> configure and build a kernel that incorporates nothing that people
> have labelled as obsolete or deprecated (or broken, etc.).

And that benefit is...? :-)

I suppose it's for example a convenient way to test-build a kernel
without deprecated stuff, run the kernel, and see if anything in
userland breaks.  Then take measures to update userland in time, or get
in touch with whoever declared the deprecation, before it's too late.

You probably have more applications in mind and maybe even posted about
them before.  (See also at the end of this mail.)

[...]
>>   - "...it's not really experimental but nonetheless claims to be. Bad
>>     craziness all around."
> 
>>     Won't adding more maturity levels increase craziness?
> 
> not at all.  in fact, what it *will* do is prevent those mismatches
> between some kernel feature visually *advertising* itself as being,
> say, DEPRECATED, while, in reality, it's *not* tagged that way.

Ah, I see.  (It gets better because you reduce redundancy of Kconfig
expressions vs. Kconfig display strings.)

[...]
>> All of the levels except BROKEN are highly subjective.
> 
> i don't think so.  we've had this discussion before, and most people
> seem to agree on what it means for something to be "deprecated" and
> what it means to be "obsolete."  it's not really *that* subjective.

Sorry, I didn't express myself clearly.  It's quite clear what the
labels mean.  But it can be controversial whether a piece of code
deserves one of these labels.  Except for BROKEN, whose applicability
can be proven or falsified.

>> And such tags can and will become outdated.
> 
> how is that different from what's happening now?

The difference is that there will be even more tags which require
attention to keep them up to date.  Although that's hardly a problem if
there is an alert maintainer or janitor, or at least an enthusiastic
user who sends a notice to LKML.

> there's stuff marked
> "EXPERIMENTAL" that appears to have been in the kernel for years.

It is sometimes true for years, although that's not the goal for
software in mainline.

> and, obviously, the only way a scheme like this is going to work is if
> developers keep their own subsystems up to date and tag them
> appropriately.

Yep.

[...]
>> I sometimes voiced my opinion that the Kconfig language and files
>> should stick to reflect the mere dependencies, while presentation
>> should be left to the UIs.  The "maturity" directive is basically a
>> variant of "config" or "depends on" with added presentational
>> information.

[of "depend on", as you clarified]

> in a way, yes, it's a variant, but it's a variant that differs enough
> from a regular "config" and "depends on" that i think trying to mix
> the two would be a horribly bad idea.
[...]
>> Of course everybody is entitled to have a different opinion and ask
>> for more presentational markup in Kconfig.
> 
> fair enough, but it's not just presentational markup, in the same way
> that EXPERIMENTAL isn't *just* presentational markup -- it means more
> than that.

"maturity" is just like "depends on" with the added feature that UIs are
supposed to print the flag onto the screen even if the user did not
enable a debug mode of the UI.

It's really nothing more.  Nobody stops you for example from writing a
derivative of make allyesconfig which says N to CONFIG_EXPERIMENTAL.

>> Something /can/ sensibly be DEPRECATED and OBSOLETE at the same
>> time.
> 
> i disagree.  in previous exchanges, most people seemed satisfied that
> those two terms were mutually exclusive.  i think the difference in
> their definitions is self-evident.

Yes, they have different meanings.  No, they are not exclusive, they are
orthogonal.

DEPRECATED = "I don't want you to build or run this if you can possibly
avoid it."

OBSOLETE = "There is other stuff which does more or less the same, and
this here could go away in the future."

[...]
> also, once a few things get tagged, then, as i mentioned before, a
> full tree build can be done in stages.  i recall andrew grumbling that
> he was still trying to get a full configuration to build.  but why try
> to do it all at once?
> 
> i'd start with an "allyesconfig" but leaving out all the DEPRECATED,
> OBSOLETE and BROKEN stuff and beat on that until it worked.  then i'd
> add in the DEPRECATED stuff and do it again.  finally, add the
> OBSOLETE stuff.  at each stage, the build might fail but, the further
> you get into it, the less a build failure should concern you.

Aha, a tool to split and prioritize an integrator's efforts to unbreak
things.  It's another of the applications you could have mentioned to
show the benefits of the facility. :-)
-- 
Stefan Richter
-=====-=-=== -=-- ===--
http://arcgraph.de/sr/

Re: random thoughts on DEPRECATED and OBSOLETE

[Stefan Richter]

I wrote:
> Robert P. J. Day wrote:
>> there's stuff marked
>> "EXPERIMENTAL" that appears to have been in the kernel for years.
> 
> It is sometimes true for years, although that's not the goal for
> software in mainline.

Because EXPERIMENTAL does not mean "is subject to currently ongoing
experiments" but rather "is unfinished code which is known to work
incorrectly sometimes".
-- 
Stefan Richter
-=====-=-=== -=-- ===--
http://arcgraph.de/sr/

Re: random thoughts on DEPRECATED and OBSOLETE

[Robert P. J. Day]

On Sat, 28 Apr 2007, Stefan Richter wrote:

> Robert P. J. Day wrote:
> > On Sat, 28 Apr 2007, Stefan Richter wrote:
> >> Robert P. J. Day wrote:

> > i think there's a real benefit in being able to say that you can
> > configure and build a kernel that incorporates nothing that people
> > have labelled as obsolete or deprecated (or broken, etc.).
>
> And that benefit is...? :-)

the same benefit you get from being able to deselect all EXPERIMENTAL
stuff -- the knowledge that you can build a fully-functional kernel
without having to rely on anything that's considered broken or
deprecated or obsolete.

at this point, i think i've pretty much bored everyone to tears making
a case for why i think there's actual value to this feature.  if
you're not convinced, there's nothing else i can think of to say that
will persuade you.

> I suppose it's for example a convenient way to test-build a kernel
> without deprecated stuff, run the kernel, and see if anything in
> userland breaks.  Then take measures to update userland in time, or
> get in touch with whoever declared the deprecation, before it's too
> late.

exactly.  being able to deselect deprecated or obsolete stuff en masse
this easily means you can figure out *way* ahead of time whether
finally removing something will cause problems, rather than suddenly
learning that only when the actual removal happens.

> Ah, I see.  (It gets better because you reduce redundancy of Kconfig
> expressions vs. Kconfig display strings.)

yup.  i'm assuming that it's a trivial change to the display routine
to add a parenthesized maturity level (or levels) to the end of the
label when you're running "make xconfig" or "make menuconfig" or ...
etc etc.

> [...]
> >> All of the levels except BROKEN are highly subjective.
> >
> > i don't think so.  we've had this discussion before, and most
> > people seem to agree on what it means for something to be
> > "deprecated" and what it means to be "obsolete."  it's not really
> > *that* subjective.
>
> Sorry, I didn't express myself clearly.  It's quite clear what the
> labels mean.  But it can be controversial whether a piece of code
> deserves one of these labels.

in the first place, that would be *entirely* the decision of the
maintainer, just as it is now.  but nothing says that starting to tag
stuff has to affect you in any way.  there should be a top-level
selection that lets you even *activate* the maturity level settings as
part of your configuration.

if you don't want to take that stuff into account, you should be able
to turn it off entirely with a single switch, as in:

  [*] Activate maturity attributes
    [*] EXPERIMENTAL
    [*] DEPRECATED
    [*] OBSOLETE
    [*] BROKEN

if you choose not to care about maturity levels, then nothing will be
filtered at all.  so everybody's happy.

> >> And such tags can and will become outdated.
> >
> > how is that different from what's happening now?
>
> The difference is that there will be even more tags which require
> attention to keep them up to date.

i don't see that being a problem.  personally, if i was building a
kernel for my system, my first attempt would be to build one without
anything tagged DEPRECATED, OBSOLETE or BROKEN.  and if that kernel
failed because a critical feature was left out of the build, i would
be *so* instantly all over the ass of the subsystem maintainer who
erroneously tagged it that way.

this wouldn't make maturity tagging harder -- it would make it
*easier*.

> Although that's hardly a problem if there is an alert maintainer or
> janitor, or at least an enthusiastic user who sends a notice to
> LKML.

i don't think it would even need that, if people change the way they
do builds by *starting* with only those features that aren't tagged
and seeing if that fails for some reason.  it would certainly be the
way *i* would start doing builds from now on.

> "maturity" is just like "depends on" with the added feature that UIs
> are supposed to print the flag onto the screen even if the user did
> not enable a debug mode of the UI.
>
> It's really nothing more.  Nobody stops you for example from writing
> a derivative of make allyesconfig which says N to
> CONFIG_EXPERIMENTAL.

sure, i have no disagreement with that.  (um ... was there something
there i was supposed to address?  it just sounded like you were
clarifying what we were talking about.)

> >> Something /can/ sensibly be DEPRECATED and OBSOLETE at the same
> >> time.
> >
> > i disagree.  in previous exchanges, most people seemed satisfied
> > that those two terms were mutually exclusive.  i think the
> > difference in their definitions is self-evident.
>
> Yes, they have different meanings.  No, they are not exclusive, they
> are orthogonal.
>
> DEPRECATED = "I don't want you to build or run this if you can
> possibly avoid it."
>
> OBSOLETE = "There is other stuff which does more or less the same,
> and this here could go away in the future."

nope.  we've been down this road before, and the consensus was that
something could be one of deprecated or obsolete, but not both.  i can
re-post those definitions if you want, or you could read about them
here:

http://kerneltrap.org/node/7593

> > also, once a few things get tagged, then, as i mentioned before, a
> > full tree build can be done in stages.  i recall andrew grumbling
> > that he was still trying to get a full configuration to build.
> > but why try to do it all at once?
> >
> > i'd start with an "allyesconfig" but leaving out all the
> > DEPRECATED, OBSOLETE and BROKEN stuff and beat on that until it
> > worked.  then i'd add in the DEPRECATED stuff and do it again.
> > finally, add the OBSOLETE stuff.  at each stage, the build might
> > fail but, the further you get into it, the less a build failure
> > should concern you.
>
> Aha, a tool to split and prioritize an integrator's efforts to
> unbreak things.  It's another of the applications you could have
> mentioned to show the benefits of the facility. :-)

i could have except i just thought of it as i was responding to your
earlier email.  :-)

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: random thoughts on DEPRECATED and OBSOLETE

[Stefan Richter]

Robert P. J. Day wrote:
> On Sat, 28 Apr 2007, Stefan Richter wrote:
>> And that benefit is...? :-)
...
> if you're not convinced, there's nothing else i can think of to say
> that will persuade you.

It didn't come across this way, sorry, but I didn't ask a priori to be
persuaded, but rather because I thought your argument (at the wiki site)
could be enhanced by pointing out the concrete applications of the
facility.  When I visited the page, it only explained how the facility
works, not what the end-use is.

[...]
>> But it can be controversial whether a piece of code
>> deserves one of these labels.
> 
> in the first place, that would be *entirely* the decision of the
> maintainer, just as it is now.  but nothing says that starting to tag
> stuff has to affect you in any way.  there should be a top-level
> selection that lets you even *activate* the maturity level settings as
> part of your configuration.

(Although if a certain number of kernel components is inappropriately
labeled, the facility becomes useless of course.)

[...]
>> "maturity" is just like "depends on" with the added feature that UIs
>> are supposed to print the flag onto the screen even if the user did
>> not enable a debug mode of the UI.
>>
>> It's really nothing more.
[...]
> sure, i have no disagreement with that.  (um ... was there something
> there i was supposed to address?  it just sounded like you were
> clarifying what we were talking about.)

You said "it's not just presentational markup", I said "it is". :-)

[deprecated and obsolete exclusive?]
>> DEPRECATED = "I don't want you to build or run this if you can
>> possibly avoid it."
>>
>> OBSOLETE = "There is other stuff which does more or less the same,
>> and this here could go away in the future."
> 
> nope.  we've been down this road before, and the consensus was that
> something could be one of deprecated or obsolete, but not both.  i can
> re-post those definitions if you want, or you could read about them
> here:
> 
> http://kerneltrap.org/node/7593

I see a discussion on OBSOLETE vs. BROKEN there, which even ended in a
consensus, but I do not see an explicit discussion on OBSOLETE vs.
DEPRECATED.  The only definition of DEPRECATED I see there is yours, and
as it is worded, it is largely overlapping with the definition of
OBSOLETE (which, as it is laid down in that thread, is mostly yours too)
--- but it is not actually conflicting with it.

Note, another classification system can be found in
Documentation/ABI/README.  That one also features the category
"obsolete", but does not include a category "deprecated".  This is
beneficial because it doesn't leave room for disagreeing interpretations
like ours, nor for any overlap in the definitions like in those at the
end of the thread you referenced.
-- 
Stefan Richter
-=====-=-=== -=-- ===--
http://arcgraph.de/sr/

Re: random thoughts on DEPRECATED and OBSOLETE

[Tilman Schmidt]

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

Am 28.04.2007 15:25 schrieb Robert P. J. Day:
> http://fsdev.net/wiki/index.php?title=Maturity_levels

You note:

> DEPRECATED and OBSOLETE at the very least, whose definitions should be reasonably obvious.

The obviousness is in the eye of the beholder. :-)

For the sake of us non-native speakers, the definitions might
bear spelling out. I know I've had my understanding of those two
terms significantly adjusted during the last discussion of them.

Thanks,
Tilman

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
- In theory, there is no difference between theory and practice.
  In practice, there is.


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

Re: random thoughts on DEPRECATED and OBSOLETE

[Robert P. J. Day]

On Sun, 29 Apr 2007, Stefan Richter wrote:

> (Although if a certain number of kernel components is
> inappropriately labeled, the facility becomes useless of course.)

well, sure, but if someone chooses to use a tool incorrectly, there's
really no way to stop them.  and i'm guessing that that sort of thing
would be quickly self-correcting based on peer pressure.  incorrectly
tagged features should become obvious fairly quickly when builds start
to break in unexpected ways.

> You said "it's not just presentational markup", I said "it is". :-)

no, it's not just presentational markup.  it's also a selection or
filtering utility, which i consider distinct from markup.  maybe we're
just disagreeing on semantics, so let's not flog this distinction.

> I see a discussion on OBSOLETE vs. BROKEN there, which even ended in
> a consensus, but I do not see an explicit discussion on OBSOLETE vs.
> DEPRECATED.  The only definition of DEPRECATED I see there is yours,
> and as it is worded, it is largely overlapping with the definition
> of OBSOLETE (which, as it is laid down in that thread, is mostly
> yours too) --- but it is not actually conflicting with it.

in a previous discussion, the definitions were pretty much as follows:

* deprecated:  while a feature is still supported, its use is
discouraged because there is a better alternative that you should
consider migrating to at your convenience.

* obsolete:  while a feature is still in the tree, it is no longer
supported and no one should need it anymore, and everyone *should* be
using the better alternative at this point.

IMHO, there is a clear distinction between those two definitions.
they are not orthogonal, they are mutually exclusive.  put another
way, there is an obvious timeline for features:

  normal -> deprecated -> obsolete

quite simply, based on the above, you can't be deprecated and obsolete
at the same time.

in any event, i don't want to drag this out too much longer.  i think
the proposal is reasonably clear, now it remains to be seen if enough
people think it's worth implementing.

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: random thoughts on DEPRECATED and OBSOLETE

[Robert P. J. Day]

On Sun, 29 Apr 2007, Stefan Richter wrote:

> I see a discussion on OBSOLETE vs. BROKEN there, which even ended in
> a consensus, but I do not see an explicit discussion on OBSOLETE vs.
> DEPRECATED.

i think this online definition matches what i have in mind:

http://www.google.com/search?hl=en&rls=GGGL,GGGL:2006-10,GGGL:en&defl=en&q=define:Deprecated&sa=X&oi=glossary_definition&ct=title

"A deprecated element or attribute is one that has been outdated by
newer constructs. Deprecated elements are defined in the reference
manual in appropriate locations, but are clearly marked as deprecated.
Deprecated elements may become obsolete in future versions of HTML. We
recommend that authors avoid using deprecated elements and attributes
whenever practical."

  note carefully how deprecated elements can still be used, but their
use is discouraged and they *may become obsolete*.  that's exactly
what i was getting at.  deprecated stuff *might* still be used;
obsolete stuff *shouldn't* be used.

rday

p.s.  just FYI, even *i'm* getting bored of this.  :-)

Re: random thoughts on DEPRECATED and OBSOLETE

[Stefan Richter]

Robert P. J. Day wrote:
> i think this online definition matches what i have in mind:
> 
> http://www.google.com/search?hl=en&rls=GGGL,GGGL:2006-10,GGGL:en&defl=en&q=define:Deprecated&sa=X&oi=glossary_definition&ct=title

"Definitions of Deprecated on the Web: [...] This term is used to refer
to /obsolete/ structures that should not be used for new applications".

Emphasis is mine.
I can agree with this and the other definitions at this search result.

> p.s.  just FYI, even *i'm* getting bored of this.  :-)

I thought so. :-)
-- 
Stefan Richter
-=====-=-=== -=-- ===-=
http://arcgraph.de/sr/

Re: random thoughts on DEPRECATED and OBSOLETE

[Stefan Richter]

Robert P. J. Day wrote:
> * deprecated:  while a feature is still supported, its use is
> discouraged because there is a better alternative that you should
> consider migrating to at your convenience.

IOW "discouraged, no {mid,long}-term commitment, alternative available,
supported"

> * obsolete:  while a feature is still in the tree, it is no longer
> supported and no one should need it anymore, and everyone *should* be
> using the better alternative at this point.

IOW "discouraged, no {mid,long}-term commitment, alternative available,
*un*supported"

Note, that's different from http://kerneltrap.org/node/7593 --- the
supported bit is new.  Why would I officially support what I deprecate?

Also, why don't we just adopt what "deprecated" and "obsolete" mean in
real life?  (English dictionaries say, one means "disapproved", the
other means "outdated" or "no longer in use".)  And if you don't find
these meanings applicable, other terms should be chosen whose
established meaning better matches what you want to express.

[...]
> there is an obvious timeline for features:
> 
>   normal -> deprecated -> obsolete

That wasn't clear (to me) from your earlier definitions.

IOW "normal" -> "obsolete and deprecated, phase 1" -> "obsolete and
deprecated, phase 2"  (using the real-life meanings of the terms here)

with the fine distinction that there is still support available in phase
1, however curious that is.

Besides, I find it unfeasible to divide a feature removal process into
two phases.  (I was involved in feature removals before and continue to
be involved in them.)

[...]
> in any event, i don't want to drag this out too much longer.

At least my pestering seems to lead to increasing precision in your
wordings.  And believe me, precision in a feature removal process is
valuable for each party involved.
-- 
Stefan Richter
-=====-=-=== -=-- ===-=
http://arcgraph.de/sr/

Re: random thoughts on DEPRECATED and OBSOLETE

[Robert P. J. Day]

On Sun, 29 Apr 2007, Stefan Richter wrote:

> Robert P. J. Day wrote:
> > i think this online definition matches what i have in mind:
> >
> > http://www.google.com/search?hl=en&rls=GGGL,GGGL:2006-10,GGGL:en&defl=en&q=define:Deprecated&sa=X&oi=glossary_definition&ct=title
>
> "Definitions of Deprecated on the Web: [...] This term is used to refer
> to /obsolete/ structures that should not be used for new applications".
>
> Emphasis is mine.
> I can agree with this and the other definitions at this search result.

you're conflating those two again.  here's my last attempt -- see the
definitions here:

http://www.w3.org/TR/html401/conform.html

and note the fundamental distinction:

deprecated:  "... User agents should continue to support deprecated
                                     ^^^^^^^^^^^^^^^^^^^
elements for reasons of backward compatibility..."

obsolete:  "... no guarantee of support by a user agent."
                ^^^^^^^^^^^^^^^^^^^^^^^
  that's it -- there's the fundamental difference.  i really don't
care if you can find other wordings that you can interpret
differently.  in *my* proposal, those two definitions are not
orthogonal, they are mutually exclusive.  period.  end of discussion.
if you can't accept that, feel free to submit your own proposal.

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================