Re: include SUMO?

Anders J. Munch writes: No MULE means you're restricted to ISO-8859-1 and UTF-8. That covers a lot, but it's not really enough to have a decently working MUA. For example, on this list I've seen all-English posts encoded in GB2312 and ISO-2022-JP. Both VM and Gnus will punt on those. If you're talking about the packages, mule-packages are not the "old" implementation of Mule. They are packages that have no hope of working without Mule, and in some cases may do destructive things without Mule. So they are distributed separately, until we have confidence that Mule is sufficiently performant to remove the --without-mule option entirely. There's really no difference between distribution mechanics for the two versions, and Vin will decide whether to apply 21.5 patches to 21.4. It will take about 15 minutes, including ten minutes off to make more coffee. In any case, the skills and time investment required to contribute to stabilizing 21.5 and those required to improve distribution mechanics are quite different; it's likely that different people will be involved. Well, for starters, most users are repeaters; they will already have packages installed, perhaps fresher ones than are available in the core tarball. Dealing with that is going to be non-trivial, aside from the wasted bandwidth. The obvious solution, maintaining multiple release tarballs, sucks, especially in betas. We have to do it for the packages, including the separation of mule-packages from xemacs-packages. But I'd rather avoid it in core. And it's really the wrong question. Why would anybody be willing to maintain XEmacs without a package distribution? The Emacs guys spend about half of their typical 6 months pretest period finding and fixing bugs in their packages, usually at the cost of deviations from upstream versions. We cannot afford be be deviant from *both* Emacs and upstream, and prefer upstream -- thus the separation of the packages from the core, and the special privileges granted to package maintainers. Since the development cycles are not synched, that could easily mean that the user would get a SUMO that is a release or two behind, depending on how old the current recommended core distribution is, and how much effort can be put into testing and maintaining installation of the packages. Maybe. It's not obvious to me that it's worth the additional effort on the release manager's part, given the inherent deficiencies of the process of producing a combined tarball. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta