Re: ELPA policy

[Chong Yidong <cyd@stupidchicken.com>]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> figure out how to do reasonable colour distance calculations for
> rendering foreground colours in shr.el.  rainbow-mode (for colourising
> colour specs in, for instance, CSS files) was brought up, that had
> similar needs, and its calculations in the same area might possibly be
> reusable by shr.el.
>
> But apparently rainbow-mode went to ELPA instead of into Emacs, even
> though it's small, it's clearly written, and it seems to be generally
> useful for anybody editing stuff like CSS or .Xdefaults files or
> anything.  So I wondered why that was...

Rainbow-mode, as presented, is a tool for colorizing strings in Emacs
buffers, the kind of neat hack that doesn't really need to be in Emacs.
From your description, it sounds like parts of it can be usefully
refactored into a general color-manipulation library, in which case we
could include that part in Emacs (preferably, using a better prefix than
`rainbow').

> If ELPA is supposed to be a repository of really special-needs code, I
> think it's a good idea.  It would be nice to have an automatic way to
> download, say, one of the Emacs-based mp3 players.  But if it's going
> to carry stuff that people do really want to have in the Emacs
> distribution, then I think it's counter-productive.  Stuff that is in
> Emacs gets loving care.  Things that live in a package repository
> bit-rot at an alarming rate.

Well, obviously it's going to be a judgement call, analogous to the
debates about what goes into distribution DVDs (with programs like Emacs
nowadays frequently not making the cut :-P).  The level of bit-rot is
dependent on the upstream package maintainers; I don't think you can
argue that packages like Auctex (or SLIME or ESS, which are not
packaged) have bit-rotted.

Some packages integrated into Emacs are no longer active upstream but
are still tinkered with by Emacs developers, but what's really happening
here is that we have effectively forked the project.  If a package on
elpa.gnu.org ends up being abandoned, there's little difference in how
we could solve the problem, except the fork would be more explicit than
implicit.