I planning a clean up of the XEmacs mailing lists, of which there are currently about nine too many. First let me apologize for the many CCs, but I wanted to make sure that everybody concerned would see the initial proposal. Discussion will continue on the XEmacs Beta Testers <xemacs-beta(a)xemacs.org&gt; list only. I don't expect to actually implement for a couple of weeks, and that list is open post. So if you are not a member of xemacs-beta, it should suffice to follow discussion via the web archives or gmane, and post comments to xemacs-beta if you have any. Implementation will be preceded by a reminder so that people can update their subscription configurations appropriately (defaults are described below). Proposed changes: The first proposal is to redirect xemacs-beta-ja, xemacs-users-ja, xemacs-nt (aka xemacs-winnt), and xemacs-mule to xemacs-beta. None are getting much traffic (perhaps all together 1-2 posts per month), so current subscribers to those lists will be automatically resubscribed to xemacs-beta with delivery turned *off*. Addresses that are currently members of several lists including xemacs-beta will be left in their current state on xemacs-beta. I realize this will mean that people could post to xemacs-nt (for example) and miss the reply, but most people don't prune addresses in replies, so that should be rare. I believe this small risk will be outweighed by the benefit of having more eyes look at one's post. The Japanese language lists could be a problem if a lot of Japanese were to be posted, but unfortunately that seems unlikely. If it becomes an issue, we can resurrect a -ja list. The second proposal is to alias xemacs-news to xemacs-beta. This is the bidirectional mail-news gateway. It has never worked well, and with almost no traffic, now is a good time to reorganize. Unlike the last times this came up, there are now reasonable alternatives such as Google and Yahoo for comp.emacs.xemacs. And I believe that since the news gateway generally doesn't work, this will get much better service for posters. Again I propose to move the subscriptions to xemacs-beta with delivery turned off, with the same rationale as above. The third proposal is relevant only to administrators of XEmacs projects resources. Currently this traffic is split into web-related, mail-related, and general admin (miscellaneous). It will be unified by aliasing the first two to xemacs-admin. The fourth point is to eliminate xemacs-binary-kits: zero traffic, no purpose anymore, since OS distros now handle this, except for the Windows native distribution we handle internally. Finally, the trickiest proposal is related to the development workflow. Currently patches enter the workflow by being posted to xemacs-patches, where they are discussed and review decisions are posted. Then when a patch is committed, CVS automatically sends a log, including a copy of the patch as committed, to xemacs-cvs. The proposal is to redirect the CVS log/patch traffic to xemacs-patches.[1] This would have the effect of having some patches appear twice on xemacs-patches (once when submitted, and again when committed). On the other hand, currently all patches appear at least once on xemacs-patches, and then again on xemacs-cvs. This redundancy would be greatly reduced, since many current patches are committed when they are submitted. This would increase the volume of traffic on xemacs-patches substantially, probably an increment of 1/3 to 2/3 of the current volume. However, most of this additional could be automatically filtered, since decide-and-commit messages will have a 'bot-generated subject like Subject: CVS update by stephent xemacs/src ... while submit-and-commit messages will have the familiar Subject: [AC] Fix minor window-config problem style of subject. This will require some discipline by the reviewer/submitters, but it should be easily automated via Didier Verna's patcher.el which is in common use. In all cases current traffic only will be affected. The historical mailing list archives will be left in place, as is (or perhaps cleaned of spam to some extent---that's one of the projects this reorganization may free up some of my time to do!) No enhancements to the archive services are considered here. Requests and proposals are of course welcome, but this proposal won't affect them. The proposed streamlined configuration is comp.emacs.xemacs* existing newsgroup xemacs-admin XEmacs project resource management (admin) xemacs-announce* low traffic, for stable and SUMO releases xemacs-beta tester/bug report list, some user issues xemacs-buildreports* "write-only" list to record test results xemacs-design* developer list for architecture, etc xemacs-mirrors* web and ftp mirror management (admin) xemacs-patches patch submission and workflow xemacs-review* "policy" board discussion (admin) * = Basically unaffected by the reorganization. The workflow as described in the beta.info document (in 21.5) is not going to change much. From the point of view of that document, the lists being merged in to xemacs-beta are already superfluous. Comments and help would be very welcome! Schedule: I expect to do some necessary testing and prototyping of various functionality for about two weeks, then proceed to implementation. Regards, Steve Footnotes: [1] My original proposal to XEmacs Review was (condensed here): xemacs-patches needs to lose the "commit-and-review" patches which are (a) available from cvs diff and (b) available from xemacs-cvs. One reasonable manual approach has been taken recently: post a "patch omitted because you can see it on xemacs-cvs" admin notice to XEmacs patches. That seems reasonable to me; xemacs-cvs would remain read-only to everyone but the 'bot, and the APPROVE/COMMIT/discussion traffic would stay on -patches. This was not supported by anyone, and opposed by at least one reviewer. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.