unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Kangas <stefankangas@gmail.com>
To: Po Lu <luangruo@yahoo.com>, Dmitry Gutov <dmitry@gutov.dev>
Cc: Eli Zaretskii <eliz@gnu.org>, JD Smith <jdtsmith@gmail.com>,
	emacs-devel@gnu.org
Subject: Re: Moving packages out of core to ELPA
Date: Mon, 19 Feb 2024 13:09:33 -0500	[thread overview]
Message-ID: <CADwFkmmpGy1xBm5fduet-676NPeYGCpkcxRvVZiN-J8qRgf1Cw@mail.gmail.com> (raw)
In-Reply-To: <87r0h9x6og.fsf@yahoo.com>

Po Lu <luangruo@yahoo.com> writes:

> Dmitry Gutov <dmitry@gutov.dev> writes:
>
>> Those who say that the costs of maintenance is tiny, seem to have
>                                                  ....
>> missed the simple statement that the built-in version has diverged
>> from its upstream 7 years ago. The maintenance is clearly not being
>                                                             ...
>> done.
>
> We stand corrected.  The cost is _zero_, not tiny.

It's not zero here.  See Bug#39992 and Bug#69171.

To be honest, I find the argument that maintaining code can somehow be
done for free surprising.  AFAICT, the only code that doesn't increase
the maintenance burden is the code that we don't have.  I'm therefore
not convinced by those that ask us to never delete anything.

If idlwave.el is not a sufficient example, I just spent some time on
private correspondence regarding another library in Emacs that I
personally have wanted to chuck into lisp/obsolete for years.  A few
weeks ago, I installed a patch someone had sent for another case much
like that.

Is that a good use of my time?  I'm not so sure.  But just ignoring
parts of Emacs and let them bitrot doesn't seem very attractive either.
I think that we do have to take some minimal amount of responsibility
for the things that we ship.

That said, we don't have too many such files -- in large part thanks to
obsoletions that have been done over the years -- but they do still
exist.  Given our highly limited resources, I think its useful to
occasionally ask ourselves if keeping this or that library around is
still worth it, and then obsolete it if it isn't.



      parent reply	other threads:[~2024-02-19 18:09 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-17 14:40 Moving packages out of core to ELPA JD Smith
2024-02-17 15:51 ` Eli Zaretskii
2024-02-17 16:22   ` JD Smith
2024-02-17 16:51     ` Eli Zaretskii
2024-02-17 17:08       ` JD Smith
2024-02-17 17:29         ` Eli Zaretskii
2024-02-17 18:52           ` JD Smith
2024-02-17 19:20             ` Eli Zaretskii
2024-02-17 20:56               ` [External] : " Drew Adams
2024-02-17 21:16               ` JD Smith
2024-02-18  6:28                 ` Eli Zaretskii
2024-02-18 12:57                   ` JD Smith
2024-02-18 13:46                     ` Po Lu
2024-02-18 14:03                       ` JD Smith
2024-02-18 14:08                         ` Po Lu
2024-02-18 14:17                           ` JD Smith
2024-02-18 14:17                         ` Eli Zaretskii
2024-02-18 14:19                           ` JD Smith
2024-02-18 14:22                         ` Po Lu
2024-02-17 17:42         ` [External] : " Drew Adams
2024-02-17 18:21           ` JD Smith
2024-02-17 18:32             ` Eli Zaretskii
2024-02-17 19:01               ` JD Smith
2024-02-17 20:50               ` Drew Adams
2024-02-18  1:55         ` Po Lu
2024-02-18  2:27           ` JD Smith
2024-02-18  3:47             ` Po Lu
2024-02-18  1:42 ` Po Lu
2024-02-18  2:14   ` JD Smith
2024-02-18  3:39     ` Po Lu
2024-02-18  7:25       ` Po Lu
2024-02-18 12:39       ` JD Smith
2024-02-18 13:08         ` Eli Zaretskii
2024-02-18 13:15         ` Po Lu
2024-02-18  7:14     ` Eli Zaretskii
2024-02-18 12:19       ` Dmitry Gutov
2024-02-18 13:06         ` Eli Zaretskii
2024-02-18 13:27           ` JD Smith
2024-02-18 13:06         ` Po Lu
2024-02-18 13:13           ` Dmitry Gutov
2024-02-18 13:51             ` Po Lu
2024-02-18 14:19               ` Dmitry Gutov
2024-02-18 14:26                 ` Po Lu
2024-02-18 14:38                   ` Dmitry Gutov
2024-02-19 18:09           ` Stefan Kangas [this message]

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=CADwFkmmpGy1xBm5fduet-676NPeYGCpkcxRvVZiN-J8qRgf1Cw@mail.gmail.com \
    --to=stefankangas@gmail.com \
    --cc=dmitry@gutov.dev \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=jdtsmith@gmail.com \
    --cc=luangruo@yahoo.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).