[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Michelangelo Rodriguez
Subject: Re: Package proposal: greader, an audio emacs reader for blind and dislexic people
Date: Thu, 31 Jan 2019 07:04:43 +0100 (CET)
User-agent: Alpine 2.21 (DEB 202 2017-01-01)

Where i can find information about how to adere at the gnu standards?i'm sorry for my perhaps trivial question, but i'm newbie in emacs development and, at the same time, i want to start to contribute to the community. in a consistent way.
Thanks in advance.

On Thu, 31 Jan 2019, Phil Sainty wrote:

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]