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

[Michelangelo Rodriguez <michelangelo.rodriguez@gmail.com>]

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