Anders J. Munch writes:
How is Mule relevant for 21.5?
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.
I hope you're not going to waste time on 21.4 distribution
mechanics, when that time would IMHO be better spent towards
getting 21.5 promoted to stable.
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.
+1 on sumo included with the 21.5+ sources. Why would anyone ever
want to install XEmacs without full packages?
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
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.
The user already solved that problem once, in downloading the
source archive. Better to take advantage of that.
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