From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: stdlib for Emacs? [was: async 1.0] Date: Mon, 25 Jun 2012 13:32:21 +0900 Message-ID: <871ul49fl6.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87vcij7rvi.fsf@mithlond.arda> <82d34r8ej9.fsf@gmail.com> <87r4t4zr9l@ch.ristopher.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: dough.gmane.org 1340598760 27047 80.91.229.3 (25 Jun 2012 04:32:40 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 25 Jun 2012 04:32:40 +0000 (UTC) Cc: emacs-devel@gnu.org To: Christopher Schmidt Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 25 06:32:39 2012 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 1Sj0yd-000577-2a for ged-emacs-devel@m.gmane.org; Mon, 25 Jun 2012 06:32:39 +0200 Original-Received: from localhost ([::1]:46209 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sj0yc-0007YY-O9 for ged-emacs-devel@m.gmane.org; Mon, 25 Jun 2012 00:32:38 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52101) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sj0yY-0007YD-Vw for emacs-devel@gnu.org; Mon, 25 Jun 2012 00:32:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sj0yX-0001W7-2h for emacs-devel@gnu.org; Mon, 25 Jun 2012 00:32:34 -0400 Original-Received: from mgmt1.sk.tsukuba.ac.jp ([130.158.97.223]:42917) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sj0yW-0001V9-Hr for emacs-devel@gnu.org; Mon, 25 Jun 2012 00:32:33 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 343253FA0861; Mon, 25 Jun 2012 13:32:22 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id EE2FB1A355D; Mon, 25 Jun 2012 13:32:21 +0900 (JST) In-Reply-To: <87r4t4zr9l@ch.ristopher.com> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta31) "ginger" b4715fcbe001 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.158.97.223 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:151146 Archived-At: Christopher Schmidt writes: > Slightly off topic... I do not agree with GNU ELPA not being applicable > for core services. I think every single package that is not absolutely > necessary for running a bare Emacs should be moved to GNU ELPA. If you want to know what that would look like, look at XEmacs. It's a win for XEmacs, but I have to suspect that win has a lot to do with getting free maintenance for the core of many packages that are core parts of Emacs, plus a different development culture (see below). The XEmacs packagization side either has a volunteer maintainer -- sometimes the core maintainer but we prefer not to burden them if another volunteer is available -- or it's done by the "XEmacs Dev Team". Note that packages maintained by the dev team typically have much longer response times, etc, even when there is an upstream. It's not obvious to me that it would be a win for Emacs to *move* those packages to ELPA, even if it would reduce duplication of effort and cooperation costs. Ask the Gnus team. > On top of that, IMO every single core package should have a copy on > GNU ELPA so one can to overwrite the native GNU Emacs one with the > one from GNU ELPA. This would decouple all packages from the Emacs > release cycle and allow bug fixes to be distributed instantly. Bug fixes are already mostly distributed instantly, by bzr. So AFAICS what you are claiming is that this would speed up distribution of bug fixes to users who don't care enough about Emacs to build it themselves. This is very unlikely based on XEmacs experience. AFAICT, such users mostly get their fixes when they are picked up by the OS distros, but guess what? The distros don't distribute upstream binary packages, they build their own from their own repos which are (near) clones of Emacs's or upstream. > On top of that, this would make actual core emacs development, > test, release and bug management a lot easier.[1] No. It only helps if package distribution is completely decoupled from Emacs distribution, but this would be very costly to the Emacs "I can hack any part of Emacs" mindset because it would require codifying a lot of APIs that are currently more or less internal. (The fungibility of "internal-ish" APIs causes me a certain amount of hair-tearing every time we do a major sync to Emacs, since XEmacs is by necessity and by preference more friendly to fixed APIs than Emacs.) It would also probably result in more integration bugs getting through to end users. > [1] I realise this would require substantial modifications to pretty > much every single aspect of GNU Emacs and GNU ELPA. Yet I think this is > an approach worth discussing. As a gross estimate, it took Steve Baur and a few others about one man-year of effort to break out the packages that were available in XEmacs 20.4 for the XEmacs 20.5 release in 1996. There are a lot more packages in Emacs now, and it would probably be more effort in total to do the same for Emacs. Even in hindsight, I don't think the package split-off in XEmacs was a mistake. It didn't turn out as well as hoped, but it could have in theory, even in the theory I have now. But Emacs is in a different situation. GNU ELPA is successful, let it grow for a while and see what happens before turning Emacs upside down. ;-)