Re: Adding advisory notification for non-ELPA package.el downloads

[Richard Stallman <rms@gnu.org>]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > In itself, it's not a big problem that GNU ELPA uses a different 
  > workflow from MELPA, but, speaking for myself, it would be good if 
  > the ELPA README (or some other document) would contain a few 
  > paragraphs explaining the differences and would cover the steps 
  > involved in such a way that they make sense for someone with a 
  > less-than-stellar understanding of git.

I agree.  I encourage the people who manage ELPA to do this.

  > With MELPA, I put my code in a publicly accessible repo 
  > that I create myself, on a service of my own choosing,
  > and then tell MELPA where to look for it.

Is there any reason we should not do this on ELPA?

If the repo that ELPA copies from is fully under the control
of the developer of that package, I don't see that it
matters greatly whether the developer installs
changes into that package via ELPA directly, or into some
other repo which then gets copied wholesale to ELPA.

ELPA managers, does the act of installing directly into ELPA give us
an opportunity to make sure something is being handled right?

  > (in my case Github)

If only the developer uses that repo system, we don't
have to be concerned with what system it is.

But if other contributors are going to be directed
to that other repo system, we would want it not to be Github.
(See https://gnu.org/software/repo-criteria.html.)


-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.