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: Finding packages to enable by default Date: Thu, 12 Dec 2013 11:59:16 -0600 Message-ID: <858uvqx85n.fsf@stephe-leake.org> References: <87mwkgb74k.fsf@yandex.ru> <52A02473.8090005@gmx.at> <87d2laq3e5.fsf@yandex.ru> <52A1890A.2010500@gmx.at> <858uvv149l.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1386871172 2327 80.91.229.3 (12 Dec 2013 17:59:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 Dec 2013 17:59:32 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 12 18:59:37 2013 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 1VrAXx-0008B9-8R for ged-emacs-devel@m.gmane.org; Thu, 12 Dec 2013 18:59:37 +0100 Original-Received: from localhost ([::1]:37982 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrAXw-0001jM-W3 for ged-emacs-devel@m.gmane.org; Thu, 12 Dec 2013 12:59:36 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48105) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrAXo-0001j4-8l for emacs-devel@gnu.org; Thu, 12 Dec 2013 12:59:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VrAXi-00025G-LO for emacs-devel@gnu.org; Thu, 12 Dec 2013 12:59:28 -0500 Original-Received: from cdptpa-outbound-snat.email.rr.com ([107.14.166.226]:64831 helo=cdptpa-oedge-vip.email.rr.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrAXi-000258-Gm for emacs-devel@gnu.org; Thu, 12 Dec 2013 12:59:22 -0500 Original-Received: from [75.87.81.6] ([75.87.81.6:52327] helo=TAKVER) by cdptpa-oedge03 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 0A/B0-14616-979F9A25; Thu, 12 Dec 2013 17:59:21 +0000 In-Reply-To: (Stefan Monnier's message of "Mon, 09 Dec 2013 21:04:34 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (windows-nt) X-RR-Connecting-IP: 107.14.168.142:25 X-Cloudmark-Score: 0 X-detected-operating-system: by eggs.gnu.org: BaiduSpider X-Received-From: 107.14.166.226 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:166342 Archived-At: Stefan Monnier writes: >> My plan is to put Ada mode 5.0 in MELPA first, in the hopes of getting >> more beta testers. Then it might move to ELPA. > > Installing it into Emacs's core just before the freeze will give you > even more testers. Yes, but also less ability to provide timely updates to fix problems. That's an advantage of ELPA that I didn't mention before. >> I don't think it should stay in Emacs core, mainly because I don't have >> write privs to Emacs core, > > As Glenn pointed out, you do. > > If you want to move it to GNU ELPA, we could do that, but then I'd want > to include this ELPA package into the Emacs tarball. That makes sense. > This said, it'd be > kind of a pain in the rear to do (lots of work to make sure the shift > from "core" to "external package" is sufficiently smooth). I have not tried packages in Emacs yet, so I can't really comment on that. A much bigger lack of smoothness will caused by the fact that this is a complete rewrite. I have been attempting to keep things as upwardly compatible as possible. But it is not even close to 100%; the major functionality in the menu is the same, and the main user options are there, although renamed with obsoleted aliases. Some of the user functions are the same, but others have changed. No one so far has complained about that, but I've only got a handful of testers so far. So I think it makes sense to leave Ada mode 4.0 in core while introducing 5.0 in ELPA. Does that mean the file names and major mode name have to be distinct? I hope not. Since ELPA packages can be updated independent of core or other packgages, managing a major change like this is easier in ELPA than in core. After 5.x is stable would be time to obsolete or delete Ada mode 5.0. -- -- Stephe