when do we remove backward compatibility definitions?

when do we remove backward compatibility definitions?

[Sam Steingold]

Hi,

Gnus has a few backward compatibility face declarations like this:

(put 'gnus-group-news-4-face 'obsolete-face "22.1")

Emacs 22.1 was released on 2007-06-02 -- over 10 years ago.

What is the policy on removing such declarations?

R releases?
M major releases?
Y years?

Where is it officially documented?

Thanks.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net
http://islamexposedonline.com http://jij.org https://jihadwatch.org
"Complete Idiots Guide to Running LINUX Unleashed in a Nutshell for Dummies"

Re: when do we remove backward compatibility definitions?

[Sam Steingold]

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

Hi,

I asked this question 3 weeks ago and got no replies:

> * Sam Steingold <fqf@tah.bet> [2017-11-02 11:04:22 -0400]:
>
> Gnus has a few backward compatibility face declarations like this:
>
> (put 'gnus-group-news-4-face 'obsolete-face "22.1")
>
> Emacs 22.1 was released on 2007-06-02 -- over 10 years ago.
>
> What is the policy on removing such declarations?
>
> R releases?
> M major releases?
> Y years?
>
> Where is it officially documented?

To salivate our thinking, here are the obsolescence annotations in the
lisp sources (the code is attached):

--8<---------------cut here---------------start------------->8---
(insert-counter-alist
 (counter-table-to-sorted-alist
  (second (elof-count-all-obsolete "..../emacs/trunk/lisp"))))
                          25.1     193
                          22.1     172
                          24.3     127
                          24.1     125
                          24.4     123
                          23.1      88
                          26.1      65
                       Org 9.0      63
                          23.2      32
                       Org 9.1      15
                    Emacs 24.1       7
                          23.3       7
                          24.5       7
      Gnus 5.10.9 (Emacs 22.1)       6
                          23.4       5
                          22.2       5
                       ERC 5.1       4
                          27.1       4
                          21.1       4
        Gnus 5.10 (Emacs 22.1)       2
                    Emacs 22.1       2
                    Emacs 23.1       2
                       Org 8.2       2
                       Org 8.3       2
 speedbar 1.0pre3 (Emacs 23.1)       2
                     rst 1.0.0       2
                icalendar 0.19       1
                     CEDET 1.1       1
                    Emacs 26.1       1
                          20.3       1
         Gnus 5.9 (Emacs 22.1)       1
                         19.34       1
                    2011-08-02       1
    CC Mode 5.31.4, 2006-04-14       1
                at least 19.34       1
                  before 19.34       1
                          25.2       1
--8<---------------cut here---------------end--------------->8---

It does look like GNU Emacs 22.1 (2007-06-02) is a good cut-off candidate.


[-- Attachment #2: Find Emacs Lisp obsolete forms. --]
[-- Type: application/emacs-lisp, Size: 2596 bytes --]

[-- Attachment #3: Type: text/plain, Size: 279 bytes --]



-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net https://ffii.org
http://think-israel.org https://jihadwatch.org http://www.dhimmitude.org
WinWord 6.0 UNinstall: Not enough disk space to uninstall WinWord

Re: when do we remove backward compatibility definitions?

[Paul Eggert]

On 11/21/2017 09:37 AM, Sam Steingold wrote:
> What is the policy on removing such declarations?
>
> R releases?
> M major releases?
> Y years?
>
> Where is it officially documented?

I don't think we have an official policy, so how about this as a first 
cut: If the oldest GNU/Linux or other GNU distribution still in 
reasonably widespread use has Emacs version N, then we don't need to 
continue to support features that were marked obsolete in version N or 
earlier.

One way to estimate what "reasonably widespread use" means is to look at 
commercial suppliers and see what they're supporting. If even (say) Red 
Hat doesn't support an old version of Emacs any more, I would say that 
the version is so old that we needn't worry about it. With that in mind, 
currently I would say that Emacs 23.1 is the oldest Emacs we currently 
need to worry about, since RHEL 6 uses 23.1 and Red Hat plans to keep 
RHEL 6 in production (which means they'll fix bugs) through 2020-11-30. 
In contrast, RHEL 5 reached end-of-production on 2017-03-17 so we no 
longer need to worry about Emacs 21.4, which is what RHEL 5 used.

According to this estimate, if a function was marked obsolete in Emacs 
23.1 or earlier, we should be able to remove it in the master branch. If 
not, we should keep it for now.

My source for the abovementioned dates is:

https://access.redhat.com/support/policy/updates/errata

Re: when do we remove backward compatibility definitions?

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 21 Nov 2017 11:54:13 -0800
> 
> > R releases?
> > M major releases?
> > Y years?
> >
> > Where is it officially documented?
> 
> I don't think we have an official policy, so how about this as a first 
> cut: If the oldest GNU/Linux or other GNU distribution still in 
> reasonably widespread use has Emacs version N, then we don't need to 
> continue to support features that were marked obsolete in version N or 
> earlier.

No, I don't think we should look at GNU/Linux distributions to
determine such a policy.  Emacs is a separate project, and shouldn't
depend on any OS distributions.

And I'm not even sure we should have a policy.  For starters, who will
implement it?

Let's instead solve practical problems with such issues.  Are there
any practical problems here?  If so, what are they?

Thanks.

Re: when do we remove backward compatibility definitions?

[Paul Eggert]

On 11/21/2017 12:03 PM, Eli Zaretskii wrote:
> Let's instead solve practical problems with such issues.  Are there
> any practical problems here?  If so, what are they?

The practical problem is that when we have cruft in the Emacs source 
code that makes maintenance harder, we sometimes would like to remove 
the cruft to simplify maintenance, so long as removing the cruft doesn't 
unduly affect users (we warned them long ago that the feature was 
obsolete, etc.).

In cases like this it's helpful to have a guideline for when we can 
simplify the code by removing obsolete cruft. For platform issues (old 
POSIX platforms that don't support newer POSIX features, for example), 
the general rule of thumb I use in Emacs and elsewhere is, "If the 
platform's supplier no longer supports the platform, then Emacs doesn't 
need to worry about supporting it either."

My attempt at writing a guideline for supporting obsolete Emacs features 
is intended to be along similar lines. It is not meant to be 
prescriptive and so I shouldn't have used the word "policy" to describe 
it. It is merely meant as a common-sense guideline for when Emacs 
features are so obsolete that they can be removed if that simplifies 
maintenance.

Re: when do we remove backward compatibility definitions?

[Eli Zaretskii]

> Cc: sds@gnu.org, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 21 Nov 2017 12:18:41 -0800
> 
> On 11/21/2017 12:03 PM, Eli Zaretskii wrote:
> > Let's instead solve practical problems with such issues.  Are there
> > any practical problems here?  If so, what are they?
> 
> The practical problem is that when we have cruft in the Emacs source 
> code that makes maintenance harder

No, we don't have any cruft, not from my POV.

> My attempt at writing a guideline for supporting obsolete Emacs features 
> is intended to be along similar lines. It is not meant to be 
> prescriptive and so I shouldn't have used the word "policy" to describe 
> it. It is merely meant as a common-sense guideline for when Emacs 
> features are so obsolete that they can be removed if that simplifies 
> maintenance.

Sorry, I'm not interested in discussing abstract policies that have no
specific problems behind them.  It's a waste of our time.  If there is
a specific problem with the variables Sam saw, let's discuss those
instead.

Re: when do we remove backward compatibility definitions?

[Sam Steingold]

> * Eli Zaretskii <ryvm@tah.bet> [2017-11-21 22:36:16 +0200]:
>
>> From: Paul Eggert <eggert@cs.ucla.edu>
>> Date: Tue, 21 Nov 2017 12:18:41 -0800
>>
>> My attempt at writing a guideline for supporting obsolete Emacs
>> features is intended to be along similar lines. It is not meant to be
>> prescriptive and so I shouldn't have used the word "policy" to
>> describe it. It is merely meant as a common-sense guideline for when
>> Emacs features are so obsolete that they can be removed if that
>> simplifies maintenance.
>
> Sorry, I'm not interested in discussing abstract policies that have no
> specific problems behind them.  It's a waste of our time.

This is not so abstract.
Let us reformulate the question: if a developer wants to remove an
obsolete feature (function, variable, face &c) - for whatever reason -
how old does the feature has to be not to warrant a conversation on
emacs-devel?

Note that the cost of obsolete features is not 0 (although probably small).


--
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://honestreporting.com
http://no2bds.org http://islamexposedonline.com http://jij.org
A bullet affects the way the brain functions even when it hits the butt.

Re: when do we remove backward compatibility definitions?

[Paul Eggert]

On 11/21/2017 01:07 PM, Sam Steingold wrote:
> if a developer wants to remove an
> obsolete feature (function, variable, face &c) - for whatever reason -
> how old does the feature has to be not to warrant a conversation on
> emacs-devel?

I think Eli is asking us for the exact set of obsolete features you'd 
like to remove. Instead of overwhelming us with the whole list of 
features marked obsolete by 23.1 or earlier, how about listing just the 
features marked obsolete in 19.34 or earlier? That should be a small 
list where we can talk about individual items and get a feel for what 
the overall problem looks like.

Re: when do we remove backward compatibility definitions?

[Sam Steingold]

> * Paul Eggert <rttreg@pf.hpyn.rqh> [2017-11-21 13:14:02 -0800]:
>
> On 11/21/2017 01:07 PM, Sam Steingold wrote:
>> if a developer wants to remove an obsolete feature (function,
>> variable, face &c) - for whatever reason - how old does the feature
>> has to be not to warrant a conversation on emacs-devel?
>
> I think Eli is asking us for the exact set of obsolete features you'd
> like to remove.

Originally I wanted to remove the gnus face aliases because they were in
the way when I fixed inheritance of their referents.

The present question, however, is not about any specific alias.
I want to know when I can remove something obsolete without a
emacs-devel discussion.
Is the answer "never"?
(I do understand that it _is_ a reasonable possible answer, and, just to
make it clear, I have no plans to mass-delete those features ;-).

> Instead of overwhelming us with the whole list of features marked
> obsolete by 23.1 or earlier,

Come one, there are just a couple of hundred of them! ;-)

> how about listing just the features
> marked obsolete in 19.34 or earlier?

these seem clear-cut:

mail/sendmail.el:(make-obsolete-variable 'mail-yank-hooks 'mail-citation-hook "19.34")
mh-e/mh-letter.el(mh-make-obsolete-variable 'mh-yank-hooks 'mail-citation-hook "19.34")

these are more controversial:

select.el:
;; Only declared obsolete in 23.3.
(define-obsolete-function-alias 'x-selection 'x-get-selection "at least 19.34")

subr.el:
;; Lisp manual only updated in 22.1.
(define-obsolete-variable-alias 'executing-macro 'executing-kbd-macro
  "before 19.34")



--
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net http://memri.org
http://americancensorship.org http://islamexposedonline.com http://camera.org
Trespassers will be shot.  Survivors will be prosecuted.

Re: when do we remove backward compatibility definitions?

[Eli Zaretskii]

> From: Sam Steingold <sds@gnu.org>
> Date: Tue, 21 Nov 2017 16:07:04 -0500
> 
> Let us reformulate the question: if a developer wants to remove an
> obsolete feature (function, variable, face &c) - for whatever reason -
> how old does the feature has to be not to warrant a conversation on
> emacs-devel?

The age is not the most important factor.  From where I stand, you can
raise an issue with removing an obsolete feature regardless of its
age, and we should discuss each such issue on a case by case basis.

Re: when do we remove backward compatibility definitions?

[Eli Zaretskii]

> From: Sam Steingold <sds@gnu.org>
> Date: Tue, 21 Nov 2017 16:57:16 -0500
> 
> The present question, however, is not about any specific alias.
> I want to know when I can remove something obsolete without a
> emacs-devel discussion.
> Is the answer "never"?

Yes, that's my answer.  Removing features should always be discussed.

Re: when do we remove backward compatibility definitions?

[Paul Eggert]

Sam Steingold wrote:
> these seem clear-cut:
> 
> mail/sendmail.el:(make-obsolete-variable 'mail-yank-hooks 'mail-citation-hook "19.34")
> mh-e/mh-letter.el(mh-make-obsolete-variable 'mh-yank-hooks 'mail-citation-hook "19.34")

Yes, removing those makes sense.

> these are more controversial:
> 
> select.el:
> ;; Only declared obsolete in 23.3.
> (define-obsolete-function-alias 'x-selection 'x-get-selection "at least 19.34")

Since this wasn't declared obsolete until 23.3 and 23.1 is still used enough, 
I'd leave it in for now.

> subr.el:
> ;; Lisp manual only updated in 22.1.
> (define-obsolete-variable-alias 'executing-macro 'executing-kbd-macro
>    "before 19.34")

22.1 is old enough so that alias can go, if you ask me.

Re: when do we remove backward compatibility definitions?

[Eli Zaretskii]

> From: Sam Steingold <sds@gnu.org>
> Date: Tue, 21 Nov 2017 16:57:16 -0500
> 
> these seem clear-cut:
> 
> mail/sendmail.el:(make-obsolete-variable 'mail-yank-hooks 'mail-citation-hook "19.34")
> mh-e/mh-letter.el(mh-make-obsolete-variable 'mh-yank-hooks 'mail-citation-hook "19.34")
> 
> these are more controversial:
> 
> select.el:
> ;; Only declared obsolete in 23.3.
> (define-obsolete-function-alias 'x-selection 'x-get-selection "at least 19.34")
> 
> subr.el:
> ;; Lisp manual only updated in 22.1.
> (define-obsolete-variable-alias 'executing-macro 'executing-kbd-macro
>   "before 19.34")

I think all of these except x-selection can be removed (on master,
please).

Thanks.

Re: when do we remove backward compatibility definitions?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > For platform issues (old 
  > POSIX platforms that don't support newer POSIX features, for example), 
  > the general rule of thumb I use in Emacs and elsewhere is, "If the 
  > platform's supplier no longer supports the platform, then Emacs doesn't 
  > need to worry about supporting it either."

I think that as long as users of the platform want to do the work
to keep supporting it, we should give them the necessary cooperation.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.