unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Po Lu <luangruo@yahoo.com>
To: JD Smith <jdtsmith@gmail.com>
Cc: emacs-devel <emacs-devel@gnu.org>
Subject: Re: Moving packages out of core to ELPA
Date: Sun, 18 Feb 2024 11:39:59 +0800	[thread overview]
Message-ID: <874je6xwxc.fsf@yahoo.com> (raw)
In-Reply-To: <AE5B926B-7C77-4323-8A02-9C5BE2FFA3AC@gmail.com> (JD Smith's message of "Sat, 17 Feb 2024 21:14:06 -0500")

JD Smith <jdtsmith@gmail.com> writes:

> That would imply that every instance of bringing a package into core
> is not a mistake

This is correct.

> , which suggests superhuman forecasting and decision-making.

Or a simple recognition of the principle that "more is better."

> But even when including a package is beneficial, situations change
> over time (>20 yrs, in this case).  It seems only prudent to
> reevaluate whether a given package still provides sufficient benefit
> given the non-zero costs associated with it.

Such costs are strictly zero, so long as the package has indeed fallen
out of interest.  The existence of maintainence work beyond the routine
copyright bump at each turn of the year suggests that there's life in
the old dog yet, and it would be vastly improper to declare it no longer
worthy of the same.

> Many which I mentioned in my initial message.  The most salient:
>
> - Reduces maintenance burdens, freeing time for packages that have
> more pressing issues. I have heard from emacs maintainers who have
> spent significant time trying to understand and fix bugs in IDLWAVE
> code that is likely unused (even by me).

Emacs developers also spend time scrutinizing and suggesting changes to
ELPA packages, which are reported through channels not unlike
emacs-diffs.  At any rate, there's nothing preventing its users from
demonstrating that IDLwave maintenance can be safely discontinued or
ignored--most of us would be more than glad to oblige.

> - Removes "tripping hazards" for users who inadvertently activate the
> mode for unrelated files and are confused (this is not hypothetical:
> I've had numerous reports).

Let's remove it from auto-mode-alist, then.

> - Cuts down on "extra noise" in, e.g., the top level Info help.

The IDLWAVE manual can be distributed separately, if that is important.

> Is this really so, in practice?  I have packages in ELPA which are
> effectively untouched except by me, other than on first ingestion.
> And they draw updates from a repo I maintain myself.  Maybe I've
> misconstrued the situation, but my understanding has been that core
> packages receive far more attention from maintainers.  And rightly so,
> IMO: everyone has them installed, after all.
>
> Also, if ELPA and core are truly equivalent, I cannot then understand
> the common strategy of "let it mature on ELPA for a few years, then
> potentially migrate to core."

I don't either.  It's a counterproductive practice that only serves to
give some of us the satisfaction of knowing that ELPA has made itself
useful.

> Because in ELPA, users must proactively opt-in to the use of the
> package.  For such users — those who have actively sought it out — in
> stark contrast to the vast majority of Emacs users, the benefits
> dramatically outweigh the costs.

The other side of this assertion is that users must opt-out of loading
packages in core, and therefore that the entire lisp directory (bar
obsolete) is loaded into every Emacs session at startup, which is
clearly untrue.



  reply	other threads:[~2024-02-18  3:39 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 [this message]
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

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=874je6xwxc.fsf@yahoo.com \
    --to=luangruo@yahoo.com \
    --cc=emacs-devel@gnu.org \
    --cc=jdtsmith@gmail.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).