From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: ELPA policy Date: Tue, 10 Nov 2015 12:06:26 -0600 Message-ID: <868u65afvh.fsf@stephe-leake.org> 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 1447178830 11222 80.91.229.3 (10 Nov 2015 18:07:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 10 Nov 2015 18:07:10 +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 Tue Nov 10 19:07: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 1ZwDJq-0000hZ-AI for ged-emacs-devel@m.gmane.org; Tue, 10 Nov 2015 19:06:58 +0100 Original-Received: from localhost ([::1]:34677 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwDJk-0004Vy-RH for ged-emacs-devel@m.gmane.org; Tue, 10 Nov 2015 13:06:52 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59955) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwDJg-0004VM-16 for emacs-devel@gnu.org; Tue, 10 Nov 2015 13:06:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwDJZ-00007p-Bj for emacs-devel@gnu.org; Tue, 10 Nov 2015 13:06:47 -0500 Original-Received: from gproxy4-pub.mail.unifiedlayer.com ([69.89.23.142]:58361) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZwDJZ-00007X-4L for emacs-devel@gnu.org; Tue, 10 Nov 2015 13:06:41 -0500 Original-Received: (qmail 8229 invoked by uid 0); 10 Nov 2015 18:06:37 -0000 Original-Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy4.mail.unifiedlayer.com with SMTP; 10 Nov 2015 18:06:37 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw2 with id fu6V1r01C2UdiVW01u6YR3; Tue, 10 Nov 2015 11:06:35 -0700 X-Authority-Analysis: v=2.1 cv=Jv9i8qIC c=1 sm=1 tr=0 a=CQdxDb2CKd3SRg4I0/XZPQ==:117 a=CQdxDb2CKd3SRg4I0/XZPQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=9i_RQKNPAAAA:8 a=hEr_IkYJT6EA:10 a=x_XPkuGwIRMA:10 a=qtqOOiqGOCEA:10 a=pGLkceISAAAA:8 a=mDV3o1hIAAAA:8 a=yj8SPYf4be9e0LXU_VAA:9 Original-Received: from [76.218.37.33] (port=50916 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZwDJP-0002XC-CJ; Tue, 10 Nov 2015 11:06:31 -0700 In-Reply-To: (John Wiegley's message of "Mon, 09 Nov 2015 11:52:28 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt) X-Identified-User: {2442:host114.hostmonster.com:stephele:stephe-leake.org} {sentby:smtp auth 76.218.37.33 authed with stephen_leake@stephe-leake.org} X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 69.89.23.142 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:193902 Archived-At: John Wiegley writes: >>>>>> 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. ELPA packages that other core code depends on (like CEDET; xref uses it - called "core ELPA packages" hereinafter) have to be in every developer's build environment everyday; the other core code has to see the current version of the package, and it has to be the same for every developer. If core ELPA packages are in the ELPA git repository, you would copy some subtrees of the ELPA git workspace into the Emacs git workspace. People have looked into doing this, but it gets messy and confusing. "git fetch" is dealing with two upstreams for one workspace. There has been talk about git submodules, etc, but nothing concrete. The alternative, which is being implemented by the :core external package feature in Gnu ELPA, and has been shown to work (but has some details to work out), is to keep core ELPA packages in the emacs git repository. Then they are part of the developer's build environment using the current git workflow, and they are included in both the emacs tarball and the ELPA package server with the current release workflows. There are two rationales for moving a package to ELPA: 1) Allow a release schedule independent of the core Emacs release schedule. 2) Reduce the size of the Emacs git workspace, which simplifies managing it. But a _core_ ELPA package must remain in the Emacs git workspace, so the only rationale for moving a core package to ELPA is for an independent release schedule. > There are three actions I'd like to take from here: > > a. That we clearly document an ELPA policy we all agree on; In admin/notes/elpa ? > b. That we move "external" packages from core into ELPA, starting with the > really big ones; It's not clear that "really big" implies "independent release schedule". "externally managed" implies that. "not used by other core code" is also a good reason to move a package to ELPA. > c. That we assess any points of friction after doing so, and adjust as > necessary. If we use the approach of keeping core ELPA packages in the Emacs git repository, there is _zero_ friction for the current core Emacs developers; the only change is in the ELPA config scripts. -- -- Stephe