Simon> (Cc redirected to xemacs-beta instead of comp.emacs.xemacs. Simon> Btw, where does mail-lib-bugs go? Haven't seen it before.) To you personally. :-) Every package has a set of ＠xemacs.org aliases: $package-bugs, $package-discuss, $package-patches, $package-maintainer. These go by default to the maintainer, in this case, you. In many cases, they go to xemacs-beta. And for complex packages like Gnus and EFS that have their own support organizations, they go to the relevant mailing lists. Simon> steve(a)tleepslib.sk.tsukuba.ac.jp (Stephen J. Turnbull) Simon> writes: Simon> I started thinking about that with MIME support in Simon> sendmail.el, but I'm not sure it is a good idea -- large Simon> parts of Gnus is dragged into mail-lib. Yes. This needs to be coordinated with the maintainers of the packages affected and with GNU Emacs. Simon> No problem with that, but it might cause some confusion if Simon> someone (not unreasonable) wanted to think like "I need Simon> qp.el, it's part of Gnus, so I grab the XEmacs Gnus Simon> package". Hm. But they would need the mail-lib package to Simon> get the gnus package to work anyway... ah, I dunno. Exactly. We need to do something about run-time dependencies for packages anyway. At present we mostly check _build-time_ dependencies; mostly they correspond to run-time dependencies so we don't see many bugs. When we do, we do the wrong thing by hard-coding a build dependency. I guess my fundamental way of thinking here is that all the internet library people have talked about this for years. I cracked Kyle up a couple of years ago by reporting a bug in base64 handling. He said, "but that's not a VM function, it doesn't have the right arguments!" I said, "well, it may be in the w3 package, but it has your name on it!" And it did---Bill P had borrowed Kyle's base64 package years earlier, and since w3's needs hadn't changed, he hadn't updated it. Gnus even has a couple of allegedly separate packages only used by Gnus. So what I'm suggesting is that someone (you, by default) take on the burden of doing the work to coordinate the packages so that they can be maintained more easily. Note that in the case of Gnus, VM, and w3, the utility libraries are nominally well-separated from the main functionality. In practice, coordinating APIs will be a pain, I'm sure. But in the long run I think it will be worth it. If you don't have the resources to actually do it, it would at least be useful to get people's views (especially yours) on why you can't do a good job right now (== what really needs to be done to get it right) on record. Or maybe we'll find a volunteer. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.