RFC: Mailing list cleanup

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 <[email protected]> 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.