RE: ELPA policy

[Drew Adams]

> This is a legitimate complaint, Drew. One of the things I want to avoid
> with ELPA is making it harder for people to contribute to than other
> alternatives.
> 
> Since pulling in data from the Web indiscriminately is not possible for
> this project (we have to make sure we're not unwittingly including code 
> without
> a proper copyright assignment), perhaps we need as an "integrator": someone
> willing to guide the update of ELPA from various sources on the Web,
> keeping an eye out for changes that might affect copyright.

I'm glad to hear that; all of it.  And thanks for replying.

> It wouldn't be too hard to setup a process that updates a local clone of
> ELPA with all your latest versions from GitHub and EmacsWiki, and then to 
> check
> over a diff of those changes before pushing them to ELPA. One might even
> suggest that you could do this yourself, as part of your own release work.
> Would that be something you'd find worth doing?

I don't want to develop anything like that; sorry.  I don't want to fiddle
with a local GIT clone.  I would be willing to identify versions of my
libraries to be pulled at specific times ("releases") from the wiki (or
from MELPA) to be put (updated) in GNU ELPA.

I doubt that my case is typical, however.  I'm not saying that Emacs Dev
needs to cater to such a case.  I'm just explaining that I update my
libraries locally, without GIT etc., and I upload updates to the wiki.
They are automatically pulled to MELPA.

What do I need to know, currently?  Only how to write some Lisp (a
library) and how to copy and paste it into a Web page.  Simple.  Maybe
too simple to accommodate by Emacs Dev.