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

[Stefan Monnier <monnier@iro.umontreal.ca>]

> founded on such changes, but the far more numerous trivial changes that
> require adjustments hither and yon, which are so much less taxing when
> all concerned components are centralized in one repository.

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, ...).  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").  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.

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.

[ And of course, we take go the hideous hack route of adding
  (put 'evil-mouse-drag-region 'ignored-mouse-command t) in Emacs's own
  code.  ]


        Stefan