Re: GNU ELPA package discoverability

[Tim Cross <theophilusx@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3230 bytes --]

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.


-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 3920 bytes --]