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.
--