From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Aaron Ecay Newsgroups: gmane.emacs.devel Subject: Re: ELPA policy Date: Sun, 08 Nov 2015 20:52:12 +0000 Message-ID: <87mvuorz7n.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1447015964 28784 80.91.229.3 (8 Nov 2015 20:52:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 8 Nov 2015 20:52:44 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii , Achim Gratz Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 08 21:52:37 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 1ZvWx3-0003ye-3p for ged-emacs-devel@m.gmane.org; Sun, 08 Nov 2015 21:52:37 +0100 Original-Received: from localhost ([::1]:48800 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvWx2-0006Gp-K0 for ged-emacs-devel@m.gmane.org; Sun, 08 Nov 2015 15:52:36 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36402) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvWwn-0006Gf-6J for emacs-devel@gnu.org; Sun, 08 Nov 2015 15:52:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZvWwm-0005wp-0Y for emacs-devel@gnu.org; Sun, 08 Nov 2015 15:52:21 -0500 Original-Received: from mail-wm0-x235.google.com ([2a00:1450:400c:c09::235]:33179) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvWwh-0005w2-AL; Sun, 08 Nov 2015 15:52:15 -0500 Original-Received: by wmec201 with SMTP id c201so59080875wme.0; Sun, 08 Nov 2015 12:52:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type:content-transfer-encoding; bh=/YvO9BWZeWe7eUAtzszTPcRj4RT6A8DK0ykmCgxndIY=; b=IZ+Mjnovgph2S3I54HjrIi2E2hwpHwuAgXBxHvL/wgi2VSP2UbgpiY5KT9V+J5DrM+ OZsOj5kUdELsCbBQXGJlRfitOO48IbER7L1TnCWCRtNo7E59p6F4xBENExkkwksSriKH K81P/0Rd9IXwL8IcBCORFR4HOyfn2ga6spPdG3JNxm43fTpFXpAhlYRr8NYSwyZveCtR 1AA1Cm8Ejv7km2INMqlyMqeIs8GZF9SwNrlw7O0qc1CrS4Z7BzFGHiai9AMhFHV82m/6 85DEaHs20MdqA6RuR4xGVkKAuL82aM9A+xXR28S7EOUhrRTLMfsLPCnStpLaazBAFgSb U2Lg== X-Received: by 10.28.88.203 with SMTP id m194mr21433167wmb.68.1447015934548; Sun, 08 Nov 2015 12:52:14 -0800 (PST) Original-Received: from localhost (host-92-30-118-26.as13285.net. [92.30.118.26]) by smtp.gmail.com with ESMTPSA id q125sm10565363wmd.5.2015.11.08.12.52.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Nov 2015 12:52:13 -0800 (PST) In-Reply-To: <83k2psnzyh.fsf@gnu.org> User-Agent: Notmuch/0.20.2+65~gbd5504e (http://notmuchmail.org) Emacs/25.0.50.2 (x86_64-unknown-linux-gnu) X-Clacks-Overhead: GNU Terry Pratchett X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c09::235 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:193657 Archived-At: Hi Eli, 2015ko azaroak 8an, Eli Zaretskii-ek idatzi zuen: [...] >=20 > Let me turn the table and ask: Are there any _advantages_ in moving > stuff like Dired, CC Mode, Shell Mode, Speedbar, and ps-print, to name > just a random few? Imagine someone implements an awesome new feature for dired. Emacs users the world over are amazed by this, and fill their blogs, twitter, etc. with the news. If dired is an ELPA package, everyone who hears this news can get the new feature in their emacs instantly by upgrading their ELPA packages. No need to wait N months for a new release of emacs, or compile a non-release version of emacs from git. Whether this counts as an advantage or not is complicated, and partially depends on one=E2=80=99s point of view. It would spell the end of an era w= here each emacs release=E2=80=99s features are explicated through a year of exci= ted blogposts (for example ). Users will be able to choose a new model where features trickle in rather than coming in sudden major chunks. This might make it more complicated to advocate adoption of new emacs versions. But I don=E2=80=99t think so actu= ally: we regularly get big features at the language level too, which are very exciting (for emacs 24 lexical binding, now dynamic modules and xwidgets, and one dares to hope for the concurrency branch in emacs26). I also think that discussion around this topic is distorted by a long-tailed distribution. Most people probably have in mind the big emacs packages with dynamic developer communities and independent release cycles. Org, Gnus, CEDET, and maybe a few others. On the other hand, it seems to me that you have in mind (in addition to these) all the tiny packages that see very few commits and perhaps no new features (in the extreme case take kermit.el, which has seen no substantive changes since at least 1992, but still gets its copyright header lovingly updated every year). I don=E2=80=99t know how to reconcile these viewpoints, or even if it=E2=80=99s necessary. Just something to consider. Speaking for myself, my primary interest in emacs development is working on org-mode, and I heavily use org as well as third-party packages for python (elpy), clojure (cider), R (ESS), and a few other random things. I build emacs from git every month or so in order to pick up little quality of life improvements, like with-eval-afer-load, some of the subr-x stuff, seq.el, the overhauled package menu, etc. But I have to make sure to keep a couple months=E2=80=99 worth of old emacsen around, in = case my monthly pull happens to land on a buggy commit =E2=80=93 one that causes regular segfaults, which I have had happen more than once. I use emacs for work so I don=E2=80=99t have the luxury of just going without for a few= days until the problem is fixed. I could go back to a previous released version of course, but then my init.el breaks because it relies on new features since the release. I=E2=80=99d be much happier running released versions of emacs for stabilit= y, if it were easier to pull in new versions of core elisp libraries as they are developed. I suspect there are some others out there like me, and many more who don=E2=80=99t currently build emacs from source for whatever = reason but would enjoy more regular access to new features in core elisp libraries. My 2 cents FWIW, Aaron PS I also have the impression that life would be easier for org=E2=80=99s maintainers under a system that freed them from merging code back and forth from org=E2=80=99s repo to emacs. This would have indirect positive effects on me as I work on org development. However, I=E2=80=99m sure the maintainers themselves =E2=80=93 and maintainers of other projects in the s= ame situation like CEDET and Gnus =E2=80=93 can speak to the question better th= an I can. --=20 Aaron Ecay