Re: ELPA policy

[Eli Zaretskii]

> From: Aaron Ecay <address@hidden>
> Cc: address@hidden
> Date: Sun, 08 Nov 2015 20:52:12 +0000
> 
> Imagine someone implements an awesome new feature for dired.  Emacs
> users the world over are amazed by this, and fill their blogs, twitter,
> etc. with the news.  If dired is an ELPA package, everyone who hears
> this news can get the new feature in their emacs instantly by upgrading
> their ELPA packages.  No need to wait N months for a new release of
> emacs, or compile a non-release version of emacs from git.

How is this different when Dired is in the Emacs repository?  The
Emacs repository is a public one, so anyone and everyone can get the
latest version from there and use it, if they want.

> I also think that discussion around this topic is distorted by a
> long-tailed distribution.  Most people probably have in mind the big
> emacs packages with dynamic developer communities and independent
> release cycles.  Org, Gnus, CEDET, and maybe a few others.  On the other
> hand, it seems to me that you have in mind (in addition to these) all
> the tiny packages that see very few commits and perhaps no new features
> (in the extreme case take kermit.el, which has seen no substantive
> changes since at least 1992, but still gets its copyright header
> lovingly updated every year).  I don’t know how to reconcile these
> viewpoints, or even if it’s necessary.  Just something to consider.

The suggestion was to move _all_ of them, except the few that are
needed for bootstrap, out of the Emacs repository.  Most of the
packages in that category are neither like Org nor like kermit.  They
are relatively small, but get quite a significant number of changes.

> Speaking for myself, my primary interest in emacs development is working
> on org-mode, and I heavily use org as well as third-party packages for
> python (elpy), clojure (cider), R (ESS), and a few other random things.
> I build emacs from git every month or so in order to pick up little
> quality of life improvements, like with-eval-afer-load, some of the
> subr-x stuff, seq.el, the overhauled package menu, etc.  But I have to
> make sure to keep a couple months’ worth of old emacsen around, in case
> my monthly pull happens to land on a buggy commit – one that causes
> regular segfaults, which I have had happen more than once.  I use emacs
> for work so I don’t have the luxury of just going without for a few days
> until the problem is fixed.  I could go back to a previous released
> version of course, but then my init.el breaks because it relies on new
> features since the release.

I don't see how the issue at hand can affect you, then.  Your usage is
very similar to mine, FWIW.