Re: ELPA policy

[Aaron Ecay <aaronecay@gmail.com>]

Hi Eli,

2015ko azaroak 8an, Eli Zaretskii-ek idatzi zuen:

[...]

> 
> Let me turn the table and ask: Are there any _advantages_ in moving
> stuff like Dired, CC Mode, Shell Mode, Speedbar, and ps-print, to name
> just a random few?

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.

Whether this counts as an advantage or not is complicated, and partially
depends on one’s point of view.  It would spell the end of an era where
each emacs release’s features are explicated through a year of excited
blogposts (for example
<http://endlessparentheses.com/tags-expanded.html#emacs-25>).  Users
will be able to choose a new model where features trickle in rather than
coming in sudden major chunks.  This might make it more complicated to
advocate adoption of new emacs versions.  But I don’t think so actually:
we regularly get big features at the language level too, which are very
exciting (for emacs 24 lexical binding, now dynamic modules and
xwidgets, and one dares to hope for the concurrency branch in emacs26).

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.

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’d be much happier running released versions of emacs for stability, if
it were easier to pull in new versions of core elisp libraries as they
are developed.  I suspect there are some others out there like me, and
many more who don’t currently build emacs from source for whatever reason
but would enjoy more regular access to new features in core elisp
libraries.

My 2 cents FWIW,
Aaron

PS I also have the impression that life would be easier for org’s
maintainers under a system that freed them from merging code back and
forth from org’s repo to emacs.  This would have indirect positive
effects on me as I work on org development.  However, I’m sure the
maintainers themselves – and maintainers of other projects in the same
situation like CEDET and Gnus – can speak to the question better than I
can.

-- 
Aaron Ecay