From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: ELPA policy Date: Wed, 18 Nov 2015 11:12:30 +0100 Message-ID: <8737w38vld.fsf@fencepost.gnu.org> References: <87ziyuaqhl.fsf@petton.fr> <867flp8nb7.fsf@stephe-leake.org> <9e33129a-07d0-4abe-a94e-32d6d881519b@default> <86bnb06g7g.fsf@stephe-leake.org> <86oaezemp9.fsf@stephe-leake.org> <1a993b13-0e96-4350-a132-7e8fb05afef4@default> <78ad3925-9441-4312-9e47-5b216ff79f18@default> <87fv07k3x0.fsf@web.de> <1c3172d6-3e2d-49b7-9d04-ac2f9465b373@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447843826 20293 80.91.229.3 (18 Nov 2015 10:50:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 18 Nov 2015 10:50:26 +0000 (UTC) Cc: Michael Heerdegen , Stephen Leake , Richard Stallman , emacs-devel To: Artur Malabarba Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 18 11:50:25 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zz0Ji-0002V9-Jc for ged-emacs-devel@m.gmane.org; Wed, 18 Nov 2015 11:50:22 +0100 Original-Received: from localhost ([::1]:35097 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zz0Ji-0001Bm-3P for ged-emacs-devel@m.gmane.org; Wed, 18 Nov 2015 05:50:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54698) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zz0Jd-00017S-As for emacs-devel@gnu.org; Wed, 18 Nov 2015 05:50:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zz0Jc-0007gR-Ag for emacs-devel@gnu.org; Wed, 18 Nov 2015 05:50:17 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54105) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zz0Ja-0007fn-RL; Wed, 18 Nov 2015 05:50:14 -0500 Original-Received: from localhost ([127.0.0.1]:39687 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.82) (envelope-from ) id 1Zz0JT-0004zk-Ko; Wed, 18 Nov 2015 05:50:07 -0500 Original-Received: by lola (Postfix, from userid 1000) id 692C7DF5EF; Wed, 18 Nov 2015 11:12:30 +0100 (CET) In-Reply-To: (Artur Malabarba's message of "Wed, 18 Nov 2015 09:53:02 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:194699 Archived-At: Artur Malabarba writes: > 2015-11-17 23:17 GMT+00:00 John Wiegley : >>>>>>> Richard Stallman 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 case. -- David Kastrup