[Top][All Lists]

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

Re: ELPA policy

From: David Kastrup
Subject: Re: ELPA policy
Date: Wed, 18 Nov 2015 11:12:30 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Artur Malabarba <address@hidden> writes:

> 2015-11-17 23:17 GMT+00:00 John Wiegley <address@hidden>:
>>>>>>> Richard Stallman <address@hidden> writes:
>>> We want people to arrange to contribute their Emacs add-ons to Emacs, and
>>> that suggests that whenever someone says a reason why he didn't want to put
>>> his code in GNU ELPA, we should try to correct it.
>> Agreed. ELPA should become a more positive experience, both for developers,
>> contributors and users.
> I'm deeply in favor of making it easier for people to contribute code
> to Elpa, and (like I said), I'm willing to help write the code for
> that.
> But I think the hardest part of the problem is not being discussed here.
> Whatever this method is, it needs to meet two criteria simultaneously:
> 1. Not commit any code to Elpa until someone with push access has OK'd
> it. This is just to ensure nothing malicious is being done.
> 2. Be fairly automated (not completely), so that the Elpa maintainers
> don't have to manually commit+push all code that gets sent to them.
> This is to preserve the sanity of the maintainers. The current model
> where everything is commited by us just isn't scalable.
> While those two points are not mutually exclusive, they are quite
> difficult to reconcile. It needs to show the maintainers a diff of the
> changes and then only proceed with the commit after receiving some
> very minimal interaction (a reply to an email, or the click of a
> button).

With the GNU ELPA requiring copyright assignments, I doubt that we are
going to hit scalability issues of the kind you fear.  But of course
there is nothing wrong with trying to create a contributing process that
is minimal effort for the sake of such archives where this is not the

David Kastrup

reply via email to

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