On Sun, 24 May 2020 at 13:53, Richard Stallman <
rms@gnu.org> wrote:
> You mention 'within the limits of our basic goals'. I don't think this has
> been clearly defined
The goal of the GNU Project is to develop the entirely-free operating
system GNU and rid the world of nonfree software. It is a very
ambitious goal, but we will push as far as we can, and we will not
give up.
Yes, but more specifically, what are the goals of ELPA (and the proposed ELPA without copyright assignment)? How are these to fit into the GNU Emacs eco-system? What should go into ELPA, what should go into Emacs 'core'? How will these ELPA archives work with GNU Emacs releases? (e.g. Do the packages in these archives need to be compliant with new release, such as not using functions flagged obsolete, using updated versions of libs/modules in emacs core etc). Will an Emacs release be held up if there is a package in ELPA that does not work with new version? When can packages be updated and what backwards compatibility with older versions of Emacs should they support? What about platforms - do packages need to support all the same platforms that Emacs supports? for the archive where copyright is assigned to the FSF, who is responsible for maintenance and updates? When should packages be removed?
> 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.
Since we will put less effort into checking and maintaining these
packages than into GNU ELPA packages, we can surely handle more
packages in it.
How many more? It isn't useful to worry about. If this is the
right approach, we will try it and see how many.
You seem to be focusing on just the new proposed non-copyright assignment repository. There is much unclear about the existing repository, including what should and should not be put there, who is responsible for making decisions and managing that resource, maintenance and life cycle maintenance of packages etc.
> 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,
Our usual approach is to try things, develop a practice that works,
then write it down. Too much advance planning is a pain, and often it
turns out not to be useful. Once we have real experience we can make
a better plan.
Which is fine provided it does get done. Has this been done for the existing ELPA repository? If so, can you point me to it as I'd like to read it to improve my understanding?
> developer should be confident [perse] now know[s] what is the appropriate
> location for [per] code
When would that question arise? In what scenario?
To put it back into context, what I wrote was -
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 think this is a common question developers would ask themselves. Simple scenario -
I have an elisp package which I wrote, which is licensed under the GPL and which I think others might find useful. I need to decide how to make it available. The package.el packaging system seems to be a popular choice, I now need to decide which repository to put it in. My choices are
- GNU ELPA (if I'm prepared to assign copyright to FSF)
- GNU Unassigned Copyright ELPA
- MELPA
- Public archive on my web site
All of these options have pros and cons. However, without adequate documentation regarding the GNU repositories, workflows and guidelines on using them and what the commitments and expectations are with respect to having a package in one of these two repositories, I'm in the dark. I cannot assess whether they are appropriate for me. To get clarification, all i can do is send a message to the list, which too often will end up in a long thread going back and forth and with little definitive outcome. I may get some clarification, but likely end up with more questions.
In the end, I decide to initially release through MELPA as it is simple and quick. I can always change later should things become clearer.
Six months later, I'm still using MELPA. Most of my questions have been answered, but now I'm use to MELPA and it is working fine and has achieved my goal, which was simply to make my package available to others who may find it useful. I'll just leave it as it is. Most Emacs users use MELPA anyway and while I believe my package could be in an official GNU archive, the work required to do that is hard to justify, plus I now have other things to work on.
The above is not an uncommon scenario. I have asked a number of package owners why they put their package in MELPA rather than GNU ELPA and the answer generally came down to two things. Number one was a perception it was just too hard - process was unclear, time it takes too long and there were just too many unknowns. The second common response was about copyright assignment - most of the time it wasn't so much about assigning copyright so much as uncertainty about what that really meant (i.e. and education issue).
Having a non-copyright assignment repository may help, but only if all the rest becomes clearer and easier. A 'build it and they will come' approach is unlikely to work - there is already a solution, MELPA. While that is not a good solution from a philosophical point of view, it is a fine solution for many who have released packages that are GPL'd and don't use or encourage non-free software. Those authors have met their moral obligations by release their software with a GPL and by avoiding use of or encourage use of non-free software. The fact other software in the repository is not compliant is not really their concern. You could argue it should be, but then you also have to take into account individual capacity and freedoms and the fact they probably would have used a more complaint repository if one had been available that did not have too many barriers.