Re: Why not include all ELPA packages in an Emacs release?

[Po Lu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> You don't need to convince me of that, but that's only one side of the
> coin.  There's also the issue of allowing/encouraging contributions from
> people who do not want to contribute to core Emacs (e.g. because they
> don't like our low-tech email-based workflow, or they don't like the way
> we argue, ...).

But that surely is a decision for individual package maintainers,
correct?  Org Mode's development procedures and practices are quite
close to ours, for instance, yet it "lives in" both core, ELPA, and
independently just the same.

> Or the fact that in many people's mind once it's in core Emacs it's in
> a kind of "long term retirement home" (tho apparently there is a
> similar belief about GNU ELPA where some people are reluctant to
> contribute a package to it before it's "complete").

In this instance, the problem is the exact inverse, which is to say that
users take prompt action on the part of (NonGNU) ELPA package
maintainers for granted, and it becomes an uphill battle to persuade
them to actively submit these trivial changes upstream, they rightly
perceiving this to be our responsibility.

> Which is why whether a package should live in core or in GNU ELPA is
> done on a case by case basis and it's usually a "lesser evil" kind of
> choice.

The greater evil, in my view, is moving packages from core to the devil
knows where.  Once a package is integrated into Emacs, its disposition
should be accomplished fact, the more so if no singularly compelling
reason (e.g., an uncooperative maintainer) emerges to move it elsewhere.
I think I mentioned why this is so.

> BTW, technically, we *can* make a change to the Evil package without the
> maintainers's agreement.  It will mean that the `elpa/evil` branch on
> `nongnu.git` will not be in sync with the upstream Evil Git repository
> (a "fork") and that we will have to keep *merging* our local changes
> with upstream updates in the future (tho that can be automated as long
> as it doesn't bump into merge conflicts), so it comes at a cost, but if
> the upstream's maintenance goes dead it's an option we should consider.

I think there is life in the old dog yet.  The difficulty is that mail
cannot be delivered to the address listed on its package description.