Re: Yeah! Using instructions missing from the README, xemacs installed! (was Re: How can xemacs have been made so hard to install? Do the developers have any clue it is needlessly hard/undocumented?)

Ben> Unfortunately, you are very right about the current situation Ben> of things. In my opinion, the creation of the package system Ben> has really been a big disaster. I suppose. Isn't it possible that it's the packaging of the package system which could be tweaked? Ben> The only things that packages seem to gain are a certain Ben> amount of disk space (which is essentially free nowadays and Ben> not worth saving), and some possible savings in download time Ben> (which is completely outweighed by the incredible headache Ben> that you have to go through in order to get things working). I appreciate being able to upgrade a package without (a) having to download and reinstall the whole thing, including preserving any local customizations in irrelevant packages (or the C source) or (b) tracing through inter-library dependencies. (b) admittedly hasn't been solved by any means, but IMO it has gotten better. Many libraries have been well-written and -organized for years, but the recent mule-base-1.32 fiasco shows that there are still major problems of maintainability in the Lisp code. The root of that problem is that the Mule lisp code is more-or-less randomly assigned to different packages (let alone files), a situation that is only slowly being sorted out. Some Mule programmers have historically considered all of Mule to be one single package, and felt free to change interfaces and access internal functions in other libraries at will. The extra enforcement of discipline through defined packages can be a good thing, improving maintainability. Ben> Before the implementation of the package system, there was Ben> one tarball for everything, and installation was easy, Ben> following the standard "configure; make; make install" Ben> paradigm. I do not understand why the SUMO tarball contains only packages. I think it was a mistake to separate the executable from the packages that way (SUMO lisp gets updated more frequently than the core tarball, but it's not that much more so, and it's error-prone). It would be better if SUMO tarballs contained all of XEmacs. Probably, according to your "disk and download are free" argument they shouldn't even have Mule separated out; there should be one SUMO tarball, containing the current release XEmacs and the package hierarchy as of the release date. (And maybe keep the preceding SUMO tarball around for a week, as the "revert to stable version.") But that is a very small change. Most users in that situation wouldn't even need to know about packages, I think. But given the rapidity with which Lisp mutates, I think that many SUMO users, especially admins of multiuser systems, would still appreciate the flexibility to upgrade single packages (and their dependencies), as I do. Ben> It is often claimed that "there is no time" to work on these Ben> things. This is obviously a bogus claim, however, because Ben> plenty of other things do get worked on, and most of these Ben> things are much less important (but often more interesting) Ben> than these basic maintenance issues. Unfortunately, this is Ben> often exactly how things go with free software projects. We are all responsible for the situation. Sure, the lead maintainer and the review committee should be (and as far as I can see are) assuming more responsibility than the average xemacs-beta subscriber, but as reasonable as the suggestions at http://www.666.com/xemacs/ (XEmacs-beta readers: have YOU visited yet this week? :-) are, reasonable people could have other ideas, especially about priorities. I've read typing.html; still, I think that if you think the situation is deplorable, you ought to find a way to deplore it _here_ on xemacs-beta every so often. (A DeploreBot ;-) that posted about once a week would be fine by me, under the circumstances.) That's the only way to create a critical mass of support[1] for changes that other leaders don't think are so important, IMO. Also, "Architecting XEmacs" proposes a bunch of organizational changes (personal mailing addresses, making the Web site CVS-based, etc); given that evidently nobody with the power to "Just Do It" is boiling over with enthusiasm to ram them through, they ought to be discussed. Here. Footnotes: [1] Ie, potential volunteers, or at least people who have spoken in favor and thus are liable to have their arms twisted. -- 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 two straight lines for? "Free software rules."