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 16:36:13 -0600 Message-ID: <86ziyl8ote.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> <868u65afvh.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447195025 505 80.91.229.3 (10 Nov 2015 22:37:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 10 Nov 2015 22:37:05 +0000 (UTC) Cc: aaronecay@gmail.com, Stromeko@nexgo.de, Dmitry Gutov , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 10 23:36:53 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 1ZwHX1-00041g-SG for ged-emacs-devel@m.gmane.org; Tue, 10 Nov 2015 23:36:52 +0100 Original-Received: from localhost ([::1]:35894 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwHX1-0002ye-GA for ged-emacs-devel@m.gmane.org; Tue, 10 Nov 2015 17:36:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32820) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwHWu-0002tW-PU for emacs-devel@gnu.org; Tue, 10 Nov 2015 17:36:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwHWr-0007zg-It for emacs-devel@gnu.org; Tue, 10 Nov 2015 17:36:44 -0500 Original-Received: from gproxy2-pub.mail.unifiedlayer.com ([69.89.18.3]:32950) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZwHWr-0007zT-Ao for emacs-devel@gnu.org; Tue, 10 Nov 2015 17:36:41 -0500 Original-Received: (qmail 3692 invoked by uid 0); 10 Nov 2015 22:36:36 -0000 Original-Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy2.mail.unifiedlayer.com with SMTP; 10 Nov 2015 22:36:36 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by CMOut01 with id fycV1r01E2UdiVW01ycYZK; Tue, 10 Nov 2015 15:36:35 -0700 X-Authority-Analysis: v=2.1 cv=VOBOwb/X 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=0ntMElN-MvqpLg9VgW8A:9 a=H7bl0rMviw7O6hMU:21 a=cYxjF_ywwSmo2-Qv:21 Original-Received: from [76.218.37.33] (port=52675 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZwHWg-0001qx-OI; Tue, 10 Nov 2015 15:36:30 -0700 In-Reply-To: (John Wiegley's message of "Tue, 10 Nov 2015 10:28:26 -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.18.3 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:193984 Archived-At: John Wiegley writes: >>>>>> Stephen Leake writes: > >> 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. > > Elpa.git should be a submodule referenced from within Emacs.git (under > "elpa"). That's overkill; there are many packages in Gnu ELPA that core code should _not_ depend on. We could try to have a list of approved packages in a file somewhere, but I don't think we can enforce that; better to use git to enforce it. We need a way to explicitly label and enforce which ELPA packages core code can depend on. The only demonstrated way to do that is to keep them in Emacs git. > This allows us to expressly state which "version" of Elpa is expected > to work with the current Emacs.git. That's only required for the ELPA packages that core code can depend on. For the other ELPA packages, we explicitly don't want to know if they work with Emacs master; that's up to the individual package maintainers. That's one of the primary purposes of ELPA. > Large packages like CEDET should move outside of Emacs.git and into > Elpa.git. If this said "large packages that the rest of Emacs core does not depend on ...", I could agree. I just checked; the only other core code that depends on CEDET is xref.el, which can be fixed. So I agree, CEDET should move to elpa git. However, I assume the reason CEDET is in Emacs git is because there is a desire to distribute it in the tarball; a sufficient number of users expect it to be there without going thru package install. So the mechanism to put ELPA packages in the tarball (but _not_ in the emacs development workspace) must also be implemented. That should not be too hard; no git submodules, just directory tree copy. So this introduces a third kind of ELPA package: "distributed in Emacs tarball". A "tarball package" for short? Except that Eric maintains that there is more to "CEDET" in Emacs core than just lisp/cedet/*. So to be clear, we are proposing to move only lisp/cedet/* to elpa git. > If xref.el depends on CEDET, it would move to Elpa.git as well. As Dmitry points out, better to remove the dependency from the core xref.el. Then we can add it back either in the ELPA CEDET package or in a new xref-cedet ELPA package. >> 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. > > I do not want this code replication. How is it replication? There are two styles of ELPA packages currently: 1) The only repository for the code is Gnu ELPA git 2) There is an external repository that the package maintainer uses; releases are pushed to Gnu ELPA git The choice is up to the ELPA package maintainer. The proposal is to change both to say: 1a) The only repository for the code is Gnu ELPA git or Gnu Emacs git. 2a) There is an external repository that the package maintainer uses; releases are pushed to Gnu ELPA git or Gnu Emacs git. The ELPA packages in Emacs git are "core ELPA packages"; core Emacs code may rely on them. There is no additional replication by keeping the core ELPA packages in Emacs git. The only reason the core Emacs packages are in the ELPA server is to allow package releases in addition to Emacs releases. The package maintainers have to accept maintaining backward compatibility, so a core package in an Emacs 25.1 binary install can work with a more recent version of the core ELPA package. In summary, I'm proposing that there are three kinds of ELPA packages: 1) "normal ELPA package". - Stored in Gnu ELPA git, and possibly in the package maintainer's separate repository. - Releases only occur via the ELPA package server, whenever the version number increments in the ELPA git main package file. - Core Emacs code may not depend on these. 2) "tarball ELPA package". - Stored in Gnu ELPA git, and possibly in the package maintainer's separate repository. - Each Emacs release includes a released version of the package in the Emacs tarball, via copy from an ELPA workspace at Emacs tarball build time. Other releases also occur, via the ELPA package server, whenever the version number increments in the ELPA git main package file. - Core Emacs code may not depend on these. 3) "core ELPA package". - Stored in Gnu Emacs git, and possibly in the package maintainer's separate repository. - Each Emacs release includes a version of the package in the tarball, because it is in the Emacs git workspace. Other releases also occur, via the ELPA package server, whenever the version number increments in the Emacs git main package file. - Core Emacs code may depend on these. -- -- Stephe