From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Filipp Gunbin Newsgroups: gmane.emacs.devel Subject: Re: ELPA policy Date: Wed, 11 Nov 2015 16:52:39 +0300 Message-ID: References: <87ziyuaqhl.fsf@petton.fr> <56401834.8080402@yandex.ru> <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 1447250011 22197 80.91.229.3 (11 Nov 2015 13:53:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Nov 2015 13:53:31 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 11 14:53:21 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 1ZwVpZ-0005pH-Oe for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2015 14:52:58 +0100 Original-Received: from localhost ([::1]:40720 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwVpU-00018I-1o for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2015 08:52:52 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52703) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwVpP-00017z-A7 for emacs-devel@gnu.org; Wed, 11 Nov 2015 08:52:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwVpL-0007Oy-EO for emacs-devel@gnu.org; Wed, 11 Nov 2015 08:52:47 -0500 Original-Received: from out4-smtp.messagingengine.com ([66.111.4.28]:36187) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwVpL-0007Oe-6Z for emacs-devel@gnu.org; Wed, 11 Nov 2015 08:52:43 -0500 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B863F20529 for ; Wed, 11 Nov 2015 08:52:41 -0500 (EST) Original-Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 11 Nov 2015 08:52:41 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=0qhVx 60UZuyE9dZx2ojRetY+qGU=; b=UetPv+1Qf5zailn24gFZSYpcV5V4wRXaYxmCd xGQri88Vbuza8HRffdWhj7by4sCn/HEgmTAdK3KKZRfwuiAGiEhzIRyCspJ5hq9m xBseF6ZB9AQb4N4yGsh8BlvG7AjjaKbSKFWXSfN3R/W3Bqc4hXUH1zaJ0j4t312S O/9UCQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=0qhVx60UZuyE9dZx2ojRetY+qGU=; b=BdBea L6+gxfPitKyPQfxcm1NHnhTopl9TdBdXMxzB0YHeXDqeMaN1v5t67uxHoe98JJ9I FlWqtzkZ6zRi6Wii8V6UM0Rn7uNjO89+pexVQaQITXHKgdk90lIJHY1SrR2gIrFC cwe7h83peD+MSuLqysDTKSZydD4yeYyUTmEq8M= X-Sasl-enc: Pso4MUCW/EQ2jGyj086gA9mTfxI4ahF2kQcQ1ULD0mgG 1447249961 Original-Received: from fgunbin.local (unknown [94.25.218.10]) by mail.messagingengine.com (Postfix) with ESMTPA id 238A3C00017 for ; Wed, 11 Nov 2015 08:52:41 -0500 (EST) In-Reply-To: <86bnb06g7g.fsf@stephe-leake.org> (Stephen Leake's message of "Wed, 11 Nov 2015 03:25:07 -0600") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (darwin) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 66.111.4.28 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:194057 Archived-At: I do not consider myself competent enough in this area, but I'd like to share some thoughts here: For each package version there is a range (possibly sparse) of core versions on which the package is supported (or just should work). 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. 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. 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). 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. 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) - 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"). - 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). A user can then decide whether to use git version of e.g. Gnus (from Elpa or private package repository) if she likes, or update to a released package version from Elpa (if core supports it), or just keep using the Elpa version she uses at the moment (which probably came together with current core). - 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). 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. Filipp