Re: GNU ELPA package discoverability

[Tim Cross <theophilusx@gmail.com>]

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

On Wed, 27 May 2020 at 13:19, 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. ]]]
>
>   > Except it isn't. There is nothing in the README about how to obtain
>   > write/push rights to the repository or that it is the same rights as
> you
>   > need to add code to the Emacs repository. It also states that if you
> don't
>   > have the necessary rights, someone will do it all for you, but with no
>   > indication on how to find that someone or provide them with the code.
> In a
>   > single file package, I guess sending the file to emacs-devel might be
>   > sufficient, but for larger projects that won't work. Relying on
> 'someone'
>   > to do the work is a vague proposition and will often result in a rather
>   > slow process.
>
> I agree that we should document how to participate in developing
> packages in ELPA.  But this is a long term need, not an urgent need.
>
> Since we are considering a big change in how people would do that,
> why document the current system?  We may as well change it, get
> the new system working well, and document that one.
>
> --
> Dr Richard Stallman
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
>
>
>
I totally agree. I think we should focus on what we want more than what we
have. We can then look at the gap between what is and what we want and
develop plans to get us from here to there.

I do think we need to clarify what should go into ELPA, what should go into
Emacs core and what is not compatible with either (I include in ELPA the
possible non-copyright assigned repository, even though it may be a
completely separate repository). Much of the 'higher level' criteria is
known (for example, GPL'd, not rely on or encourage use of non-free
software etc) and some has contention (i.e. ELPA v Emacs core). Eli has
made reference to a previous proposal, which might be a good staring point
if someone has a copy.  Once we know how ELPA will be used, we can
determine the best way to structure it so that developers can submit new
packages for inclusion and maintain these packages such that barriers to
developers are minimised while maintaining the level of control the GNU
project requires without imposing too much additional burden on those who
volunteer to help maintain the repository. Overall object would likely be
something along the lines of making GNU ELPA a viable first choice for
appropriate packages over MELPA.


-- 
regards,

Tim

--
Tim Cross

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