From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: John Wiegley Newsgroups: gmane.emacs.devel Subject: Re: ELPA policy Date: Mon, 09 Nov 2015 11:52:28 -0800 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> <83ziynma4s.fsf@gnu.org> <5640C6A0.5010709@yandex.ru> <83twovm9es.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447098789 16384 80.91.229.3 (9 Nov 2015 19:53:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 9 Nov 2015 19:53:09 +0000 (UTC) Cc: aaronecay@gmail.com, Stromeko@nexgo.de, emacs-devel@gnu.org, Dmitry Gutov To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 09 20:52:59 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 1ZvsUq-0002Dk-O8 for ged-emacs-devel@m.gmane.org; Mon, 09 Nov 2015 20:52:56 +0100 Original-Received: from localhost ([::1]:55245 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvsUq-0002mE-0A for ged-emacs-devel@m.gmane.org; Mon, 09 Nov 2015 14:52:56 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49034) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvsUa-0002lp-PZ for emacs-devel@gnu.org; Mon, 09 Nov 2015 14:52:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZvsUZ-0006qq-Nr for emacs-devel@gnu.org; Mon, 09 Nov 2015 14:52:40 -0500 Original-Received: from mail-pa0-x235.google.com ([2607:f8b0:400e:c03::235]:34653) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvsUV-0006qM-Pb; Mon, 09 Nov 2015 14:52:35 -0500 Original-Received: by padhx2 with SMTP id hx2so200241974pad.1; Mon, 09 Nov 2015 11:52:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:in-reply-to:date:message-id:references :user-agent:mail-followup-to:mime-version:content-type; bh=1CYwWrtakkrZ8GWvp7pTSpBBI0ADNZ9FdxsiXNd62fE=; b=ETGBgSG5Q8rZFQ1VQGaCyTYP86OyQMIMuu8ce7ch2i5Ol28htxJx2rqeDrbepsV//C Ox5D/3aKwtyITvZrL/8lEWErhhdv5/elZlCB2WQjEs8R+DrfT2dIChvoBJoqvtrxXU0e M2cYrwT4zT/Q/CtpEkzfYpjwz4dw/xqYTtxnq9BZHEsXiV4hlvkSPEf8WryYFd34M2JU cKGCr73F0MqRDDVvGGotxoRIpKsVsjaQhcXSM9jYygJTIxdKpRrGHARYh3q9+g5P2noE YjI+ssRalBx1hN/OiPhcv95SMssn/TjQT2emlgOoBp7IHwW8XhtzI4rNfZFr3cOV9X4p go1g== X-Received: by 10.68.177.5 with SMTP id cm5mr43388195pbc.92.1447098755211; Mon, 09 Nov 2015 11:52:35 -0800 (PST) Original-Received: from Vulcan.attlocal.net (76-234-68-79.lightspeed.frokca.sbcglobal.net. [76.234.68.79]) by smtp.gmail.com with ESMTPSA id eg5sm17957071pac.30.2015.11.09.11.52.33 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 09 Nov 2015 11:52:33 -0800 (PST) X-Google-Original-From: "John Wiegley" Original-Received: by Vulcan.attlocal.net (Postfix, from userid 501) id AB38B103F8E68; Mon, 9 Nov 2015 11:52:32 -0800 (PST) In-Reply-To: <83twovm9es.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 09 Nov 2015 18:20:43 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (darwin) Mail-Followup-To: Eli Zaretskii , Dmitry Gutov , aaronecay@gmail.com, Stromeko@nexgo.de, emacs-devel@gnu.org X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c03::235 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:193743 Archived-At: >>>>> Eli Zaretskii writes: > It was made before -- that's the "let's move Org and Gnus out" variant, to > which I said I could easily agree. And then there was the "move everything" > one, to which I object for the reasons stated. What I meant was that there > was no 3rd variant, AFAIR. Wow, a lot of discussion about ELPA policy, this is great. We definitely have an opportunity here to bring clarity to an area that is on people's minds. I agree with a lot of what I read, although it was a too spread out for me to add specific quotes here. Let me just summarize a possible path forward: 1. Things that are maintained by the core Emacs developers should be in core, and in the Emacs.git repository. This makes it easy for them to access and build, search history, read emacs-diffs, etc. 2. Things that are maintained outside of Emacs, but contributed back for inclusion, should be in ELPA, and in the Elpa.git repository. This includes Gnus, Org, CEDET, and a few more. (We don't want to go crazy, so let's start with the big ones). 3. There should be a defined subset of packages that get copied from ELPA into the Emacs tarball during release, and an easy way to manage this list for the core developers. That way, certain packages like seq.el and stream.el can feel like "core" packages to users, when they are really "external" packages from the point of view of the core developers. 4. Everything else in ELPA is Internet-installation based, as it is today. I would very much like for ELPA to be a way to: - give the core developers a smaller surface area to focus on; - allow ELPA package maintainers to "have their package in Emacs", while retaining nimble in their own development process and in delivering updates to users; - allow the core maintainers to decide what exactly is going into "Emacs": For example, I wouldn't want to pull Org releases into the distribution from a submodule; I really do want a version of that source code to be in ELPA, so we can separately patch if there are last minute problems. ELPA should thus benefit core developers by reducing load, and benefit package maintainers by being an easier platform for their contributions and their users. If it causes extra work for anyone, that's something I'd want to change. There are three actions I'd like to take from here: a. That we clearly document an ELPA policy we all agree on; b. That we move "external" packages from core into ELPA, starting with the really big ones; c. That we assess any points of friction after doing so, and adjust as necessary. John