bug#50999: [External] : bug#50999: 29.0.50; Deleting libraries obsolete since Emacs 24

[Drew Adams <drew.adams@oracle.com>]

> > How about telling people to not report bugs in those packages?  For
> > instance, a disclaimer stating "this is obsolete and unsupported -- use
> > at your own risk".
> >
> > Perhaps report-emacs-bug could detect that case, and warn the user.
> 
> If we distribute code, then we'll be fixing bugs in that code.  I don't
> think there's any way around that.

I don't agree.

For a long time Emacs even distributed a "contrib"
directory with code provided by others.  It had
the right licenses, but was in no way maintained
or "fixed" by Emacs dev.  It was likely vetted at
the outset, at least in a superficial way.

And there are libraries in Emacs today that are
NOT considered obsolete and yet have undergone no
maintenance in years, sometimes even decades.

It doesn't follow that continuing to distribute
"obsolete" code imposes an obligation on Emacs dev.

There's no obligation to make changes to _any_
Emacs code (with the possible exception of a
moral obligation to fix moral and security bugs).

> We choose what code to introduce into Emacs, based on many things, but
> among them is a consideration whether we think that the feature will be
> useful to many people or not.  It's the same consideration when removing
> features -- if we think that it's not used, then we remove it.  (And we
> find out by making it obsolete and seeing whether there's any
> complaints.)

Obviously some people think that some (maybe even
all) of the "obsolete" code is useful.  Why not
keep it?

What is really gained by removing "obsolete" code?
I think the answer is "nothing".
___

Same goes for closing many bugs that are recognized
as bugs but that no one is _currently_ apt to try
to fix.  It's logical to keep them open, but some
might think it looks good somehow to close them.
Closing bugs is not the same as fixing them.

(One opinion.)