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: Wed, 11 Nov 2015 15:22:22 -0600 Message-ID: <861tbwcju9.fsf@stephe-leake.org> References: <87ziyuaqhl.fsf@petton.fr> <83ziynma4s.fsf@gnu.org> <5640C6A0.5010709@yandex.ru> <83twovm9es.fsf@gnu.org> <868u65afvh.fsf@stephe-leake.org> <87lha5snji.fsf@isaac.fritz.box> <87d1vhsmuj.fsf@isaac.fritz.box> <878u65slue.fsf@isaac.fritz.box> <874mgtsjwn.fsf@isaac.fritz.box> <867flp8nb7.fsf@stephe-leake.org> <9e33129a-07d0-4abe-a94e-32d6d881519b@default> <86bnb06g7g.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447277008 5601 80.91.229.3 (11 Nov 2015 21:23:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Nov 2015 21:23:28 +0000 (UTC) Cc: emacs-devel@gnu.org To: Filipp Gunbin Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 11 22:23:12 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 1ZwcrI-0007xm-Ba for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2015 22:23:12 +0100 Original-Received: from localhost ([::1]:43065 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwcrI-0004zQ-BW for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2015 16:23:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41215) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zwcr1-0004wr-Qm for emacs-devel@gnu.org; Wed, 11 Nov 2015 16:23:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zwcqr-0006gQ-Dp for emacs-devel@gnu.org; Wed, 11 Nov 2015 16:22:55 -0500 Original-Received: from gproxy2-pub.mail.unifiedlayer.com ([69.89.18.3]:59811) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Zwcqr-0006fl-6B for emacs-devel@gnu.org; Wed, 11 Nov 2015 16:22:45 -0500 Original-Received: (qmail 3159 invoked by uid 0); 11 Nov 2015 21:22:38 -0000 Original-Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy2.mail.unifiedlayer.com with SMTP; 11 Nov 2015 21:22:38 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw2 with id gMNV1r00A2UdiVW01MNY34; Wed, 11 Nov 2015 14:22:36 -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=nF_HO72G02MA:10 a=qtqOOiqGOCEA:10 a=IKNSx4zdZj_F959RoTMA:9 Original-Received: from [64.19.11.18] (port=25613 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1Zwcqc-0001rY-L7; Wed, 11 Nov 2015 14:22:30 -0700 In-Reply-To: (Filipp Gunbin's message of "Wed, 11 Nov 2015 16:52:39 +0300") 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 64.19.11.18 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:194149 Archived-At: Filipp Gunbin writes: > For each package version there is a range (possibly sparse) of core > versions on which the package is supported (or just should work). For normal ELPA packages, that's true. For core and tarball ELPA packages, they must work in each current Emacs release (since they are in the release tarball). They may also support some set of previous Emacs releases. > While the intent to move as much as possible in ELPA can be understood, > it leads to potentially more incompatibilities between important parts > which can provide API by themselves. Yes. > So, there should be some compromise between "latency" of new features > before they generally become available for use in packages and overall > core stability. To me, it seems that the latter is more important and > it's better to keep infrastructure & library things in core, while > moving everything that uses them for a concrete purpose to ELPA. For normal ELPA packages, that's true. But this is partly why core and tarball ELPA packages are being considered. > If that in turn provides some API which others use, then we have > package interdependencies and that is probably OK (but can lead to > conflicts). A more flexible requirements spec may be needed. For example, Debian packages allow specifying a range of versions in the dependency; that can reflect actual testing, and not rely on implicit promises of future backward compatibility. Of course, it can also lead to false failures. > If sufficient amount of important packages use some API and that API > is rather mature, then the maintainer can decide to move that in core > to simplify dependency management. or to a tarball ELPA package, or to a core ELPA package. Perhaps that is too much choice? > So, I'd suggest that: > > - Language features go straight into core (and people working on them > / using them will have to use git version of Emacs until next > release) By "language features" do you mean things like ada-mode.el (primary mode for editing Ada source files)? If so, I strongly disagree; ada-mode.el is very happy as a normal ELPA package. Similar modes for other languages with a small audience could be in ELPA as well; I have not looked to see what's actually there. cc-mode is the core for a lot of similar C-like languages, so it probably makes sense to keep that in core. But it would be interesting to see what the consequences of moving it to a normal or tarball ELPA package would be. But if you mean things like parsers and xref support, then I agree. Although ada-mode also provides its own parser ... > - New libraries which are not supposed to be in very common use go to > ELPA first > - Then they are probably promoted to core as they get mature and more > widely used - just to simplify their usage ("they will always be > available"). That's what tarball ELPA packages are for. The only reason to move a package to actual core (ie emacs git, as opposed to elpa git) is if some other core code wants to depend in it. > - Major applications (like Gnus) and smaller ones always go to ELPA > (most probably we should also bundle them in a tarball, but keep > outside of the core). Right; that's a tarball ELPA package. > - If such an application provides things useful for other > applications, then it probably should extract that into a library to > go through the cycle oulined above (elpa --maturity--> core). Yes. > The API / SPI notion can also be used to provide implementations > (backends) for different features which may have default simple > implementations in core and more advanced ones in packages. A package > must somehow "register" itself as a candidate for being a service for > a concrete feature during installation. If we use cl-generic to provide dispatching, the cl-defmethod form does the registration. -- -- Stephe