NB: xemacs-design currently doesn't exist---please direct traffic to xemacs-beta. Once the new ML system gets settled, we can revive -design if people think it's needed. Didier Verna writes: AUCTeX is a special case. David has been extremely uncooperative and has been mildly abusive toward Uwe Brauer who volunteered to maintain the XEmacs package. If Uwe wishes to drop the package, that's fine by me. However, I find the XEmacs package very useful for my personal needs, and others do too. The only solution acceptable to David is for us to distribute the pseudo-package produced by the AUCTeX team verbatim. I see no point in that; if we're going to drop support for the package, we should just point users to the AUCTeX site. (We should consider mirroring it in as-is/ or something, which I guess would be up to Norbert's time and effort so he should have final say, but it should not live with the packages that we claim to support.) Other packages with obsolete versions we should fix. IMHO YMMV etc. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

René Kyllingstad writes: And if I commit something to core that breaks it, what do you suggest? If it's updated and is dead-on-arrival because of changes to 21.5 that the AUCTeX team (which last I heard had *zero* regular users of XEmacs in its core group) isn't up to date on, what do you suggest? Where should those bug reports go? What do we do with those packages while waiting for a fix? I *definitely* don't think such packages should go into the SUMOs. As for "needing special configuration," IMO the package manager has long been deficient in that respect; it should be improved to offer all the versions of a package that it knows about. Now, there are well-known problems that arise with 3rd-party Emacs Lisp that is not built in a "clean" environment. The XEmacs package system has been very successful in forestalling most of those (thanks in part to Mats Lidell's "smoke test", M-x all-hail-mats RET), without the delays involved in waiting for a core release tested with all the packages. I don't want to give that up. OTOH, there are plenty of packages that don't need "helium atmosphere builds" to work acceptably well; AUCTeX is evidently one. x-symbol is another. The package manager ought to support convenient installation and removal of a "contrib" or "as-is" category of binary packages that *we* don't care if they break or not (but mostly they don't ;-). I think that would be a better place to direct core developer effort than dealing directly with AUCTeX (that currently doesn't build in our "clean" environment). _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

René Kyllingstad writes: David won't like that. He can't do anything about our SUMOs---which is the reason this thread is happening. Doing it that way requires a commitment on our part to responding to AUCTeX development in a timely fashion. As you point out, core developer effort is at very low levels. This proposal means extra work for the core, so it's not a solution, unless you spell it "v o l u n t e e r". Specifically, *somebody* must track the AUCTeX releases, and update our package lists. *Somebody* must rebuild the SUMOs. *Somebody* must forward the bug reports to AUCTeX and follow up on their fixes. If Norbert is willing to sign on to those tasks (and pragmatically, he has to do the SUMO builds), you're golden. If not, you're on the spot; you need to offer the support that goes above and beyond what he's already doing. In principle, the beta testers deserve better, not worse, support than the stable users. You should also remember that our package tree is shared with SXEmacs, which is no longer even close to being a mere clone of XEmacs 21.4, and is under quite active development AFAIK. Furthermore, for many, perhaps most, non-USian Windows users 21.4 is no longer acceptable because of its many defects in handling Unicode on Windows. This is probably also true for SuSE Linux users, which AFAIK abandoned the stable line a while back because it isn't compatible with their build procedures (where have I heard that reason before?) and functions unacceptably in a fully UTF-8 environment. So I don't think that's close enough to an acceptable workaround to be considered anything but a serious defect in your proposal. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta