A proposal for removing obsolete packages

[Andrew Hyatt]

I'd like to propose a policy for feature removal - I'll just start out
with the policy, and then give the rationalization, and discuss
alternatives.

Currently, obsolete elisp is moved to the obsolete subdir. Attempts to
load them are successful, but come with the warning message "<package>
is obsolete!" I propose that we leave them in the obsolete subdir for
one major version. At the start of every new major version, we remove
everything from that subdir package that has been there since the start
of last major version.

For example, a package that is declared obsolete during the development
of Emacs 25 would be moved to obsolete, and a message would be added to
say that "<package> is obsolete and will be removed in Emacs 27". It
couldn't be removed in Emacs 26 because it didn't start Emacs 25 in
obsolete.

In short, obsolete package added in the middle of a release will be
guaranteed to exist until the next major release, and then one more
major release.

The need for a policy arose while discussing with Eli and others what
should be done with a bug against the obsolete longlines-mode
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=1452). We have many bugs,
and it was a bit worrying that there was no way to remove a bug even
against functionality that was obsolete. Plus, there was no accepted way
to get anything out of obsolete. Where was the benefit, then, of putting
things in obsolete at all?

To me, it's clear that emacs would be well served by shedding some
little-used functionality. The amount of elisp is enormous, and it
mostly modifies a common user experience, so that each package can
potentially create problems for each other package. By removing the
obsolete packages, we can reduce the amount of potential issues.

What if someone relied on an obsolete package? Mostly, like
longlines-mode, better solutions have come along. Giving people an
entire major version to switch seems pretty reasonable to me. For most
obsolete functionality, we're talking years of existence in the obsolete
subdir. If not, anyone still interested can create an ELPA package that
they maintain on their favorite ELPA server - but not in gnu ELPA.

There might be even better solutions to this problem. I certainly have
not attempted to explore the entire space of solutions. Perhaps the
timing is too long as well - I wouldn't mind making things more
aggressive and instead removing all obsolete packages at the start of
each major version (meaning that an obsolete package would last one
major version or less). This probably would work itself out and obsolete
packages would tend to not be removed at the end of the major version
development cycle.

Please let me know what you think.