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: Re: CVS is the `released version' Date: Mon, 21 May 2007 17:47:12 +0900 Message-ID: <87veem7ecv.fsf@uwakimon.sk.tsukuba.ac.jp> References: <2cd46e7f0705101124r72000f78xdf05d18ca815ca57@mail.gmail.com> <17991.47259.210100.801472@localhost.localdomain> <85d50wq6a9.fsf@lola.goethe.zz> <853b1qg358.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1179736620 15702 80.91.229.12 (21 May 2007 08:37:00 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 21 May 2007 08:37:00 +0000 (UTC) Cc: tromey@redhat.com, rms@gnu.org, joakim@verona.se, emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 21 10:36:58 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Hq3Nx-00028l-Fj for ged-emacs-devel@m.gmane.org; Mon, 21 May 2007 10:36:58 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hq3Nv-0002Th-VD for ged-emacs-devel@m.gmane.org; Mon, 21 May 2007 04:36:56 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Hq3Nr-0002TY-Nn for emacs-devel@gnu.org; Mon, 21 May 2007 04:36:51 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Hq3Nq-0002T9-7H for emacs-devel@gnu.org; Mon, 21 May 2007 04:36:51 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hq3Nq-0002T6-36 for emacs-devel@gnu.org; Mon, 21 May 2007 04:36:50 -0400 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Hq3Nf-00044c-Hn; Mon, 21 May 2007 04:36:40 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id A88231535AC; Mon, 21 May 2007 17:36:26 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id DA5BC1A2965; Mon, 21 May 2007 17:47:13 +0900 (JST) In-Reply-To: <853b1qg358.fsf@lola.goethe.zz> X-Mailer: VM 7.17 under 21.5 (beta27) "fiddleheads" (+CVS-20070324) XEmacs Lucid X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:71473 Archived-At: David Kastrup writes: > Please take a look at how the XEmacs package system works. It has a > central repository. It tends to distribute outdated or non-working > code because the people maintaining the central server tend to be not > the same creating the packages. I wish you'd stop generalizing from your experience, which is limited to AUCTeX and is unrepresentative of the general experience. Furthermore, your reporting of the features and operation of the XEmacs package system bears almost no resemblance to the reality. So let's take a look at how it does work. In fact, most of our packages (that are not maintained by the GNU Emacs project) are maintained by their upstream maintainers. They generally simply make a commit to the XEmacs CVS repository, which starts the release process using XEmacs resources, including rolling and announcing tarballs, a pretest period, and a second announcement when the pretest is over and the release is promoted to "public release" (of the XEmacs package). Only if bugs are reported, or if the maintainer wishes to give special instructions (eg, more commits are coming, don't release yet) is there need for anything more than a cvs commit by upstream. (AUCTeX differs because for many years its upstream maintainer has been publicly at odds with the XEmacs project and has explicitly claimed that the user who has volunteered to maintain the XEmacs package is unqualified, and thus has forfeited control over our package to our volunteer.) Regarding centralization, if you want *us* to distribute packages with storage and bandwidth contributed to *us* and want *us* to do the work of rolling the tarballs and so on, then indeed we do insist on checking in to our CVS. For almost all changes to packages, it's simply a matter of copying over the new version to a checked-out XEmacs tree, and typing "cvs commit -m 'Release of version X.Y.Z.'" in the package subtree of the XEmacs tree. This is no different from getting your package to be released as an official Emacs library, using GNU resources: you have to check into the GNU CVS repo. We do insist that "official XEmacs" packages be built in the context of a full package tree, for precisely the same reasons that GNU Emacs "wants" to be a monolithic application: Emacs Lisp provides no facilities for proper modularization (the only namespace is the global one), and there is no way to achieve inlining (required for Lisp macros and extremely desirable for defsubsts) from bytecode. Note that for this reason Tom Tromey's package.el will likely be quite popular with upstream maintainers, compared to the XEmacs system. It's Emacs-oriented, so you can assume that the environment will contain all of the wonderful "stuff" distributed with Emacs. Most of the complexity of the XEmacs system derives from the fact that that assumption is easily violated in a modular package system, while in practice it won't often be a problem for users of monolithic Emacs. For end users, in fact, there is no problem with using multiple package archives. (Admittedly, I'm personally not at all happy with our UI for using multiple archives. But that's an implementation problem, not a bug in the basic design.) Nor does the UI make any attempt to distinguish between mirrors of the "official" archive and private or upstream project archives. VM, for example, has maintained a private archive distributing its "latest and greatest" version as an XEmacs package for at least 5 years. Many users use that package in preference to ours. Others prefer the convenience of one stop shopping. > If some package is provided upstream, we want to have it directly > usable from its default download location. XEmacs's package system has that feature, and has always had it, by design. Cf VM. There's nothing to stop you from distributing a package compatible with our download and install UI. In fact, AUCTeX, like VM, does. The VM and AUCTeX sites are not available from the package configuration menu, but that's only because Kyle doesn't particularly want the traffic, while there are "personal issues" involved in the lack of an AUCTeX entry. However, in the end I have to agree with Richard Stallman. One big problem (for GNU) with a package system is that it facilitates distributed development and permits a general topology (rather than a star) for the distribution network. Thus it undermines the incentive to work in the context of the Emacs project and to assign code to the FSF. That's inconsistent with my understanding of the goals of GNU, and therefore of the Emacs project. Stefan Monnier is also correct that properly supporting a package system requires that exported APIs be designated and respected (ie, backwards compatibility be maintained in the face of clearly better alternatives). In XEmacs practice, any API used by a package in the CVS package repository is exported, unless we've explicitly labelled it as internal. In effect, any third party can "out" an API simply by calling it. Conflicts are rare, but annoying when they do occur. This is a perennial complaint of core developers in XEmacs (especially Ben Wing, but by no means limited to him). Since GNU wants to encourage development to happen inside of GNU, not outside of it, it seems silly to constrain Emacs that way. I conclude that until distributed development becomes an explicit goal of the Emacs project, a package system is generally counterproductive to the objectives it espouses (by which I mean advocating free software and supporting organizations in the free software movement, and developing Emacs itself as opposed to third party libraries).