From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artur Malabarba Newsgroups: gmane.emacs.devel Subject: Re: New ELPA policy proposal (was: ELPA policy) Date: Mon, 9 Nov 2015 13:51:31 +0000 Message-ID: References: <87ziyuaqhl.fsf@petton.fr> <87fv0labbf.fsf@web.de> <87y4eda0kl.fsf@petton.fr> <22074.42230.156669.584780@retriever.mtv.corp.google.com> <87ziyoxvdp.fsf@Rainer.invalid> <83k2psnzyh.fsf@gnu.org> <87mvuorz7n.fsf@gmail.com> <8337wfon3f.fsf@gnu.org> <56401834.8080402@yandex.ru> <87611bh19q.fsf_-_@gmail.com> Reply-To: bruce.connor.am@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1447077120 27666 80.91.229.3 (9 Nov 2015 13:52:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 9 Nov 2015 13:52:00 +0000 (UTC) Cc: emacs-devel To: Oleh Krehel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 09 14:52:00 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 1ZvmrQ-0001pZ-9N for ged-emacs-devel@m.gmane.org; Mon, 09 Nov 2015 14:51:52 +0100 Original-Received: from localhost ([::1]:52799 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvmrP-0000Z7-JI for ged-emacs-devel@m.gmane.org; Mon, 09 Nov 2015 08:51:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58191) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zvmr7-0000YA-JF for emacs-devel@gnu.org; Mon, 09 Nov 2015 08:51:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zvmr6-0000DL-LB for emacs-devel@gnu.org; Mon, 09 Nov 2015 08:51:33 -0500 Original-Received: from mail-lb0-x231.google.com ([2a00:1450:4010:c04::231]:36347) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zvmr6-0000DH-Dm for emacs-devel@gnu.org; Mon, 09 Nov 2015 08:51:32 -0500 Original-Received: by lbblt2 with SMTP id lt2so80019842lbb.3 for ; Mon, 09 Nov 2015 05:51:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=h8CgOhMWb8RVV07qIxhEXSZ5zI7NkMBuh0eZkUTN1sA=; b=KRNu4iHnNFdQqa9iELIfWhA3JVFzAHNlRcmP4ULvHO+U02hMqXTuJgS4lP96N/l6s7 GAQ9vgOPjFYn2b+GJSZeCeGutdzFlMotzlzlEHrqUkx2iIraOhZiPLf43BW1j9TfxAcS 0yuCe9cLmDLDY9uZH09p7lQUf3ACju2kSINEDdb6Hz9HV5MgTr9vegAeXbDYNi1cnl3E eDwwRgZ4vynW0IX5sstfnrutwqxIMNilps3P+zD7jjvbQFGLvJ+WSf+dOhKmcMwWjVFN d+6WXq7qDgM0S8VsD3+Cnbn5LjsLPibijHQEF2nSSsvUN1rZ/ZcBLccGV73uvdMeL6qR PnpA== X-Received: by 10.112.35.196 with SMTP id k4mr13910047lbj.3.1447077091635; Mon, 09 Nov 2015 05:51:31 -0800 (PST) Original-Received: by 10.112.63.70 with HTTP; Mon, 9 Nov 2015 05:51:31 -0800 (PST) In-Reply-To: <87611bh19q.fsf_-_@gmail.com> X-Google-Sender-Auth: V2BKr7_tYWop51mNAgCECHLmlRs X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::231 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:193708 Archived-At: 2015-11-09 11:15 GMT+00:00 Oleh Krehel : > 1. Only packages which are relatively independent are allowed to be > moved to ELPA. This is a rule that we adhere to right now, I just wanted > to re-state it. And it's important for the next point. > > 2. Each package is developed it its own Git repository, and is included > into the common ELPA directory as a Git submodule. No actual code is > ever committed into the Emacs git repository, only the commit hashes, > when an ELPA package maintainer deems it appropriate to merge, Two Things: * The first and simplest issue here is that we would lose control over the code on Gelpa. We can still remove any package from Gelpa entirely, of course. But it would be difficult for the Emacs maintainers to edit a package on Gelpa that's doing something wrong. For instance, Stefan has edited several of my packages in the past (which I'm grateful for), and he wouldn't have been able to do that if the source wasn't on elpa.git. But maybe that's just a cost that needs to be paid if we want Gelpa to scale. * Another thing to remember is that we need to be able to trust that code made available by Gelpa has been properly copyright assigned. The current way we do that is to: 1. Only make available code that has been pushed to elpa.git. 2. We trust those with push access to only push code that's been assigned (to the best of their knowledge). 3. We trust that those who submit code are not lying about its origins. IIUC, your proposal is that new releases would be marked by editing a file in the Gelpa repo and adding a hash of the relevant commit. This sounds more or less ok: 2. The manual edit of a hash would still have to be done by people with push access, so only they could ultimately make new code available on Gelpa. 3. The act of a developer asking us to edit a hash could be considered analogous to the act submitting a package (i.e., they are declaring that all the new code in that commit has been properly assigned, just like they originally declared so when first submitting the package). > 3. On Emacs release, we'll have emacs.tar (for people with low > bandwidth) and emacs-with-elpa.tar (the recommended download). I'm perfectly in favor of this. And it's pretty much independent of the points above. Of course, the inner workings of Gelpa affect how the build-script might create this emacs-with-elpa.tar, but they don't affect the feasibility or difficulty of this task. So it's just a matter of someone writting the necessary scripts/documentation for the next release.