Re: Making it easier for new installs

Byrel Mitchell writes: This has long been a sore point with new users, but most new users nowadays use OS package managers or (on Windows) the standalone installer. To be frank, I don't consider new users who don't get over that hump worth spending much of my time on. They simply do not contribute back to the project anyway, mostly not even useful bug reports. "It's too much trouble." (Where have I heard that before? Oh, yeah, when you were installing XEmacs in the first place, eh?) Certainly, folks like Alan Mackenzie (CC Mode maintainer) also report annoyance with it, and I'd like to address their needs as much as possible. But I suspect Alan would prefer that I work on fixing the syntax cache bugs. I don't object to serving new users who just want to install XEmacs and never think about it again. And there are plenty of folks in between, who are frustrated by the initial install issues, maybe sufficiently so that we do lose contributions. I just don't think the loss to XEmacs from placing low priority on that compares to the cost in terms of time that could be spent on other development needs or on releases. Steve Baur decided that. But he passed away in February, so we can't ask him any more. I suspect that basically it's stuff that used to be in the lisp/prim (for "primitives") subdirectory, that didn't have an obvious place to go and wasn't needed for building XEmacs proper. I do know that one of his goals was what the extreme programming crowd later labelled "DRY". Most serious language projects maintain several stable versions of their product (eg, Python currently has *six*, GCC has at least 3) for years, giving them varying degrees of attention as they age. Emacs, on the other hand, only has *one*, and the users and 3rd party developers are expected to pay the price of backward incompatibility. We can't afford to do the former for a GNU Emacs-sized distribution, and as a in-the-trenches software professional, Steve did not want to settle for the Emacs style either.[1] So a small core supporting separate packages (mostly externally maintained), each with its own -- mostly independent -- development cycle, was a central goal. It constrains XEmacs to be backward compatible, and enforces modularity. I believe it does make those libraries easier to maintain and create, at the expense of making it harder to add features to the core. Feel free to populate the etc/bundled-packages directory in recent 21.5 and provide the necessary Makefile scaffolding. I haven't had time to think about how to deal with the problem of *where* to install those packages (or even *whether*, for people who already have packages installed). I think you will find that "a couple of lines in the Makefile" is insufficient for supporting the wide variety of systems out there. You're also going to need to deal with the tarpit of configure.ac. OTOH, maybe it will be a lot easier than I think. :-) Footnotes: [1] Later, when working for Cisco in 2007-2010, he fond himself supporting no less than 7 corporate-approved versions of Emacs and XEmacs. He said it was often quite annoying that he had to deal with minor variations in APIs for GNU Emacs. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta