KJ> Martin Buchholz writes: KJ> Maybe. It's true if you believe that all that code is our KJ> responsibility. One point of breaking out the packages is that KJ> we no longer are responsible for the quality of all the code KJ> that claims to run under XEmacs. The stuff distributed ouside KJ> the core XEmacs is not part of XEmacs anymore. Your statement KJ> is false if you believe in the new reality, as I do. KJ> I'm serious. We need to stop thining of every piece of Lisp in KJ> the package tree as being part of XEmacs and our responsibility. KJ> Today's model more clearly reflects reality. We could put all KJ> the code back into the distribution and pretend that we were KJ> doing quality control. But that doesn't mean QC will actually KJ> get done. Past evidence indicates that it won't, which is part KJ> of what drove us to push the ever increasing pile of Lisp code KJ> out of the distribution. What an interesting idea. I don't think this statement of responsibility is anywhere on the web site. If we claim to only try to support the XEmacs core, then we're not really trying to provide a functional editor at all. XEmacs without packages is not an Emacs at all. Or there have to be separate projects that provide a complete editing solution, with XEmacs at the core. Then we could put up a disclaimer at ftp.xemacs.org, directing newbies to other sites that provide actual editors, if that's what they want. Anyways, Kyle, I think your idea is crazy. It's the Linux kernel without Linux CDROM distributors. Only the lunatic fringe would use it. (Dear readers: sorry, but the fact that you're reading this puts you into the lunatic fringe) It might make sense to have supported and unsupported packages, (and the supported ones are seamfully bundled with XEmacs), but we're not currently doing this either. KJ> Getting a stable XEmacs is the same as getting a stable working KJ> environment involving an operating system and some number of KJ> applications. Unless you get the whole bundle from a vendor, KJ> there will be some experimentation involved in getting a setup KJ> you're satisfied with. Almost everybody gets the whole bundle from a vendor. Linus does, for example. Steve is the rare exception who tries to maintain his own personal version of Linux. KJ> Well, that's certainly provocating enough to get discussion KJ> going. :) KJ> My opinion: the XEmacs audience is largely computer professionals KJ> who will have no problem using 'tar' (or similar) and installing I want XEmacs to be a useful tool for everyone. KJ> the packages they need to get work done. So I think providing a KJ> fancy interface over the package system is largely a waste of KJ> time. We need a way to keep unstable packages from the stable KJ> ones, so the user gets a choice. We need a way for the user to KJ> easily see what they need to install to get a certain feature. What I don't understand is that the user had a choice before the package system. How hard is running rm -rf lisp/vm One could even provide a GUI around this operation. Providing the individual packages as little tarballs has not really made the user's life any easier. Instead, the work which is _required_ to get a vaguely functional editor has gone up tremendously. Again, the user should be able to get an excellent editor by following these simple and obvious steps: tar xf configure make make install After that, the user should be able to customize to his heart's content, including removing and adding new pieces of functionality. How the content of that user tarball is subdivided into development projects is up to us. Martin

APA> I assume it's Steve L. Baur, whose disappearance from APA> xemacs-.*(a)xemacs.org is still a mystery to me. Ask him. He replies to personal mail, eventually. More than that I am unwilling to say. APA> One field is called `standards-version'. Currently all APA> packages in APA> /anonymous＠ftp.xemacs.org:/pub/xemacs/packages/package-index.LATEST.pgp APA> have a 1.1 standards-version. How about bumping this standards-version to 21.2 for all packages known[1] to only work with (emacs-version>= 21 1)? No. Don't overload that field. Decide what functionality is needed in the package system, and add fields to support it. `standards-version' will get bumped as a side-effect of this, but only the package system should ever test that field. APA> Then it should be fairly easy to change to PUI UI to offer APA> the users to upgrade to the latest package of a certain APA> standards-version. The default could be a standards-version APA> of APA> (string-to-number APA> (format "%d.%d" emacs-major-version emacs-minor-version)) APA> to make things easy for the novice user. Although rms probably will never use the package code, you might want to put the flavor of emacs in there anyway. Make the name of the field `required-emacs-version' or something like that. The main implementation difficulty with this idea is not in the pui front end, however. It's in the back end, the archives. We need to figure out how users with needs for older package versions can get them. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

KJ> I'm serious. We need to stop thining of every piece of Lisp KJ> in the package tree as being part of XEmacs and our KJ> responsibility. mb> What an interesting idea. I don't think this statement of mb> responsibility is anywhere on the web site. So? Fix the web site, because this _is_ the _de facto_ state of affairs. One thing that the package system has done is to attract lots of new packages, and somewhat increased the maintenance by decreasing the burden on package maintainers. IMHO of course. (Not clear whether it's an improvement in package maintenance, because the package maintainers have their own priorities.) The former effect has clearly outweighed the latter in terms of QC; there are a lot more packages with a lot more ways to get broken. But we've also done a lot of the breaking ourselves, by changing the XEmacs core. Shit, Martin, you just admitted to breaking Gnus yourself. That wouldn't have been prevented by keeping Gnus in ./lisp/gnus, would it? That's what happens in an active development branch. It's not clear to me that you are distinguishing between the kind of breakage that seems to bug people on c.e.x (./configure; make; make install fails to produce the expected XEmacs because there are no packages), and the kind of breakage that occurs in the development branch. One kind of breakage that is a real problem, and would be prevented by depackagizing, is the stuff that occurred when Tomo updated mule-base halfway, and broke all the Mule installations with infinite recursion in the environment-setting code. But that is a problem with the lack of a real Mule API. Maybe mule-base should go back into the core until such a beast has been defined, like all the libraries that are really internal. mb> Anyways, Kyle, I think your idea is crazy. It's the Linux mb> kernel without Linux CDROM distributors. Only the lunatic mb> fringe would use it. (Dear readers: sorry, but the fact that mb> you're reading this puts you into the lunatic fringe) No, it's much more than a kernel. I've used an xemacs 20.4 --with-x=no --with-almost-everything-else=no,too statically linked as my primary editor on my '486 linux 2.0 router for about three years, and it beats both vi (for functionality) and full XEmacs (which won't fit onto the 40MB of free space, including /var and /tmp) with a stick. No loadable lisp at all, everything I _need_ is in the core. (Sometimes I'd like efs/dired, I admit, but not enough to rebuild it. Maybe when --with-pdump starts being the default in beta versions....) mb> It might make sense to have supported and unsupported mb> packages, (and the supported ones are seamfully bundled with mb> XEmacs), but we're not currently doing this either. And who's volunteered to manage this? KJ> Getting a stable XEmacs is the same as getting a stable KJ> working environment involving an operating system and some KJ> number of applications. Unless you get the whole bundle from KJ> a vendor, there will be some experimentation involved in KJ> getting a setup you're satisfied with. mb> Almost everybody gets the whole bundle from a vendor. Linus mb> does, for example. Steve is the rare exception who tries to mb> maintain his own personal version of Linux. Even if you get the whole bundle you have to manage it. Debian broke CVS recently for example. We could easily create the basis for "themed" XEmacsen by figuring out some way to create and distribute "<theme>-package-base.el". This could integrate well with a compleat-XEmacs (ie, including SUMO) tarball by allowing the user to then delete what they don't want. mb> The packagizing of XEmacs has been bad for XEmacs. Oh, yeah? The amount of functionality provided by XEmacs in packages is substantially more than that provided by the Lisp distributed with FSF Emacs IMO. Mostly it works. And it definitely makes my life easier, q.v. I've also tried a number of Lisp libraries that I would have ignored if I had to fetch them from an FTP archive and figure out how to install and configure myself. One is PSGML, which I now use daily. Do we have the manpower to maintain all that as an integral part of XEmacs? The FSF maintains a fraction of it; they do little if any of the synching work that we do; they have a lot more manpower AFAIK. I think we would have a problem trying to maintain everything we now distribute as part of the package system. KJ> My opinion: the XEmacs audience is largely computer KJ> professionals who will have no problem using 'tar' (or KJ> similar) and installing mb> I want XEmacs to be a useful tool for everyone. So does Kyle, I imagine. But who's going to pay the price? KJ> the packages they need to get work done. So I think providing KJ> a fancy interface over the package system is largely a waste But what you described _is_ a pretty fancy interface. None of the major Linux distributions have managed that trick satisfactorily yet, AFAIK. Debian's dselect would probably work for XEmacs though, with its paltry few-score packages. It just doesn't scale to Debian unstable's 4500+ list of packages. KJ> of time. We need a way to keep unstable packages from the KJ> stable ones, so the user gets a choice. We need a way for the KJ> user to easily see what they need to install to get a certain KJ> feature. mb> What I don't understand is that the user had a choice before mb> the package system. How hard is running mb> rm -rf lisp/vm mb> One could even provide a GUI around this operation. Sure. But you picked the easy operation, didn't you? It is much easier today to update VM than it used to be. In fact, several times I have retrieved a bleeding-edge VM, adapted the packaging from the existing XEmacs package, screwed something up, removed it via the XEmacs package manager and reinstalled the working one from ftp.xemacs.org. (Not a VM issue---the point is to postpone fixing _my own_ breakage until I have time. VM is just the package that I do that kind of thing with often.) This is not an operation I would want to try with un-packaged Lisp without twice as much time available. Adapting the packaging is a trivial task---that's not where the time goes. It's when the Lisp file structure gets reorganized, and our auto-autoloads starts picking up files that shouldn't be there or vice versa that getting XEmacs working again gets hairy. But with the package system this is taken care of for me. And I don't want to think about what could happen with vc and vc-cc both in the core. Packages have made things easier for this member of the lunatic fringe. mb> Providing the individual packages as little tarballs has not mb> really made the user's life any easier. Instead, the work mb> which is _required_ to get a vaguely functional editor has mb> gone up tremendously. As Steve has pointed out numerous times, anybody who wants to combine an xemacs-<major>-<minor> release with SUMO in a single tarball can do it. Steve disagreed with the concept, and refused to implement it. His right, even if probably he's wrong. But you could have done this already for 21.2.x, your right, and could probably get Vin Shelton to do it for XEmacs 21.1.x simply by providing a script and saying "please." Has somebody vetoed this? Furthermore, you could pick a set of package versions that you will declare by fiat to be the baseline, and anybody who changes part of the core XEmacs and breaks the baseline packages gets strangled with a three-day-old udon noodle. There would be no problem identifying them and archiving them because they would live in a tarball called xemacs-MM.m-baseline-SUMO, which would be owned not by the package release engineer, but rather by the stable and development branch release engineers. (Agreed, this model as proposed is pretty clumsy but you could refine it.) -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

Andy> How many packages are actually likely to get feature creep Andy> that is backwardsly incompatible? It depends on how far back you want to be compatible. Also whether the particular creeping feature was used by the package in question before. I think it's very difficult to assess ex ante, but we have seen these problems already. I think the mule-base problems with setting environment are indicative of the kind of problems you can run into. Emacs Lisp has never really had a module concept, so APIs are a sometime thing. I know that the ETL Mule developers have never really hesitated to change de facto APIs and then fix things that break. And we spend significant effort synching with the FSF's Emacs; a lot of this is due to the fact that APIs are evolved, not defined, rather than actual new functionality. Also, people who for whatever reason are using an old XEmacs might want to use a newly-released package. This didn't use to really be a problem, since people who went off, downloaded, installed, and customized new libraries in their .emacs were pretty sophisticated. But the package-user interface makes this a lot easier. Andy> It seems to me you could pick a small subset (mule-base, Andy> xemacs-base?) of packages that you want to tie to a specific Andy> major number whilst letting the others freefall. If it's really an issue of _tie_ then they should not be packages, they should be in the core. I think package installation should normally check for XEmacs version on an relatively advisory basis, eg "Warning: this package was developed under XEmacs 21.8 and using it with an earlier version of XEmacs or with a non-XEmacs GNU Emacs is untested and may involve some breakage." In general, at run-time packages should rather be doing (require 'feature); it's only where APIs change that a warning is needed. If breakage is actually reported, the package maintainer would have the choice of fixing the breakage or upgrading the warning from "untested and may involve some breakage" to "unsupported and has been reported to involve significant breakage; you should only install this package if you are willing to deal with that breakage yourself." -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."