On Fri, 22 May 2020 at 13:11, Richard Stallman <
rms@gnu.org> wrote:
[[[ 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. ]]]
> Clarify what ELPA is for, how it is managed and what the process is to get
> a package into ELPA, then streamline this process and provide an efficient
> workflow for package maintenance and many may begin to use ELPA more and
> rely on MELPA less. Even more importantly, ELPA might become the definitive
> archive for good quality, stable and GPL compliant Emacs packages.
We are looking at how to do this, within the limits of our basic
goals. I'm thinking about making a second ELPA which won't require
copyright assignment.
Which is possibly a good idea. However, I think there are more basic questions and issues which need addressing first.
You mention 'within the limits of our basic goals'. I don't think this has been clearly defined and/or does not have consensus. Start by defining the core rationale and goals for a GNU elisp archive. Whether we do or do not need a second ELPA is just an implementation detail. First, have clarity and agreement on what the goals are and then consider the implementation.
Decide whether we need just one or more GNU elisp archives (maybe called ELPA and XXX, maybe not, maybe actually separate archives or maybe tagged differently - again, implementation details). Something which will need to be considered at this point is available maintenance resources. For example, at a high level, having a stable and reliable archive of elisp packages which are guaranteed to be GPL compliant and do not reference, link-to or encourage the use of non-free software, but does not require assignment of copyright to the FSF may be a worthy goal. However, if the resources are not available to maintain such an archive and or adding/updating code in the archive becomes a slow process because approvals take too long (because there are insufficient resources), it simply won't work. A big reason MELPA has been so popular is the overhead associated with getting code into that repository is low and once in, maintenance overhead (updates, patching etc) is trivial.
Define guidelines to help developers decide where is the best location for their library, module, extension etc. After reading these guidelines, a developer should be confident they now know what is the appropriate location for their code i.e. Emacs core, a GNU ELPA repository or some external repository (which does not need to be specified or referenced in the guidelines, it is just an external repository). These guidelines should also articulate what the on-going responsibilities and expectations are with regard to on-going maintenance of the code in each location (Emacs core, GNU ELPA).
Document process workflow, the steps a developer needs to follow in order to get their code into the appropriate place and how to manage bugs, patches, updates and releases. Developers need to understand what they are committing to before making the commitment.
--