From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Oleh Krehel Newsgroups: gmane.emacs.devel Subject: New ELPA policy proposal (was: ELPA policy) Date: Mon, 09 Nov 2015 12:15:29 +0100 Message-ID: <87611bh19q.fsf_-_@gmail.com> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447067748 2920 80.91.229.3 (9 Nov 2015 11:15:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 9 Nov 2015 11:15:48 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 09 12:15:31 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 1ZvkQ7-0003MV-Jf for ged-emacs-devel@m.gmane.org; Mon, 09 Nov 2015 12:15:31 +0100 Original-Received: from localhost ([::1]:51866 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvkQ7-00076Z-5j for ged-emacs-devel@m.gmane.org; Mon, 09 Nov 2015 06:15:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47875) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvkQ2-000763-OC for emacs-devel@gnu.org; Mon, 09 Nov 2015 06:15:27 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZvkPz-0005k0-Cl for emacs-devel@gnu.org; Mon, 09 Nov 2015 06:15:26 -0500 Original-Received: from mail-wm0-x22b.google.com ([2a00:1450:400c:c09::22b]:34216) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvkPz-0005jw-64 for emacs-devel@gnu.org; Mon, 09 Nov 2015 06:15:23 -0500 Original-Received: by wmnn186 with SMTP id n186so97157818wmn.1 for ; Mon, 09 Nov 2015 03:15:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:references:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=3vpxY1H6ghZKrpdTIO7471WgYRiEsMK9+G/1tzI6UDM=; b=vWBKMVo5LtgFCPQOuhZ1JsLiajBT9jsD2hCDhkc+l4nc81EvAZE3fUcU+WQAU7FpNn cyP1kJxxXwNIocnMwjJr3WlMTPIQvi96qku8VLdsrwB/hlWidTRn5sZmYi2o0S5YQdzn dqSthOaLxXj276p/0AdWMi+Nstz1IC7EB70Bi4aBIpecRiQ9Dw+ihBhF1BAOgDIJUjeL 9qf8a6q9BAwdOwkvksgMaVT6dkSpekF9Wban0sjzD0ISfKxnqY66k4PKqdtmv70gvMkE h8M4Sl9Y8o41oZ8LO6z96BgcJqtzLWYxPve8oBltkEP6iiT3jEFoTiF3y+eUDpGaXRHr TEmg== X-Received: by 10.28.7.67 with SMTP id 64mr24052029wmh.70.1447067722352; Mon, 09 Nov 2015 03:15:22 -0800 (PST) Original-Received: from firefly (dyn069045.nbw.tue.nl. [131.155.69.45]) by smtp.gmail.com with ESMTPSA id l81sm13750421wmb.2.2015.11.09.03.15.21 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 09 Nov 2015 03:15:21 -0800 (PST) In-Reply-To: <56401834.8080402@yandex.ru> (Dmitry Gutov's message of "Mon, 9 Nov 2015 05:51:16 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c09::22b 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:193700 Archived-At: Hi all, In the previous thread, a few concerns were posted: 1. Having ELPA separate from Emacs requires internet access to install extra packages, which might be undesirable. 2. Merging all ELPA commits into Emacs might be too noisy. 3. Waiting for new core features until Emacs release, as opposed to obtaining them immediately from ELPA. Here's my proposal to address these issues: 1. Only packages which are relatively independent are allowed to be moved to ELPA. This is a rule that we adhere to right now, I just wanted to re-state it. And it's important for the next point. 2. Each package is developed it its own Git repository, and is included into the common ELPA directory as a Git submodule. No actual code is ever committed into the Emacs git repository, only the commit hashes, when an ELPA package maintainer deems it appropriate to merge, e.g. the package is assumed to work fine with the current Emacs git version, at the moment of the merge. Then there will also be some script, like $ make elpa that will update all packages with "git submodule update". In my opinion, this is very close the model of MELPA - a very successful Emacs package archive with 2786 packages to GELPA's 130. The only difference here is that the updates aren't automatic, and are instead up to the maintainer, which should give more stability. 3. On Emacs release, we'll have emacs.tar (for people with low bandwidth) and emacs-with-elpa.tar (the recommended download). The user will have several options to configure the Emacs installation: a. Only core Emacs. b. Core Emacs with a separate offline ELPA repository. The user will be able to install from this offline ELPA repository at any time. This should be a nice default option, I think. c. Emacs with all ELPA packages installed, because why not? 4. Thanks to the version system, it will be possible to update these "offline" ELPA packages with the current online version, just like it's currently possible to have the GELPA version of a package to update to the MELPA version. Additionally, with the feature of pinning a package to an archive, we give the user the flexibility to pin ELPA packages to the offline ELPA repository, instead of having them update automatically from GNU ELPA. regards, Oleh