Re: Package proposal: greader, an audio emacs reader for blind and dislexic people

[Phil Sainty]

On 2019-01-31 16:13, Tim Cross wrote:
> The thing about GNU ELPA is that all the packages in there are
> actively maintained and kept up to date with current version of Emacs.
> The mor packages in there, the more work is required to release new
> versions of Emacs.

I don't believe that's the case at all.

GNU ELPA packages are not part of core Emacs, and anyone can contribute
them (within the FSF rules).  If new Emacs releases might be held back
on account of any arbitrary ELPA package not working, this is the first
I've heard of it.  Maybe certain packages which are considered
particularly important might have such status in effect, and obviously
if bugs are reported against ELPA packages then they could be fixed,
but I don't think adding ELPA packages increases the amount of work
required to release new versions of Emacs?

After all, one of the acknowledged advantages of ELPA packages is that
they can be updated outside of Emacs release cycles, so it is *less*
important that ELPA bugs be fixed prior to an Emacs release, because
they can be fixed afterwards without the need of another Emacs release.


> IMO the GNU ELPA repository is really for packages that represent
> core Emacs functionality. For non-core things, we have MELPA, which
> sounds like a better fit for this package.

Definitely not true.  GNU ELPA and MELPA are simply two instances of
package archives.  There are plenty of packages in GNU ELPA which are
nothing like "core" functionality, and plenty of packages in MELPA
that I wish had been contributed to either GNU ELPA or Emacs core.
It's not the case that the two archives were established for the
purposes you've described.  The only distinction I draw between them
is that one requires contributors to follow the FSF rules, and the
other does not.


> Regardless, I think the better approach is to first develop and
> release the package in MELPA. If it becomes popular and the community
> believes it would be a good fit for GNU ELPA, it can be moved over to
> that repository.

That can be a recipe for failure.  Too many packages get contributed
to MELPA, get popular, and then *can't* be "moved over" to GNU ELPA
because the author wasn't taking care of the copyright issue while it
was on MELPA, and suddenly finds that they've accepted code 
contributions
into their package which are blocking that move.  The more popular the
package becomes, the more likely that situation is to occur.  It's
better to start in GNU ELPA and ensure that this problem is avoided
from the outset.

(There's a LOT of good elisp out there which would benefit Emacs core,
but which will never do so because by the time it was "good enough" for
that to happen, it was also completely impractical to assign the 
copyright
to the FSF.)


-Phil