kde-cvs mailinglist reorganization

[Rob Kaper]

I have 10,000 unread messages in kde-cvs and it bothers me. I realize I
could set up client-side filters, but that would still be a waste of
bandwith for both me and KDE.

A couple of the options that have crossed my mind (and were briefly
discussed on the bus to Frankfurt from N7Y and previously on this list):

- Have extra mailinglists per module. This doesn't mean kde-cvs as is needs
  to go, as it'll still be ALL in CVSROOT/loginfo, but it allows for
  smaller distributions channels alongside the existing one. In fact,
  Atlantik commits are already also sent to atlantik-cvs at mail.kde.org. This
  is - safe for the extra mailinglist administration - by far the easiest to
  maintain and configure.

- Replace kde-cvs mailinglist software with our own mail injection
  application that allows for server-side filtering per user. More work,
  more flexible. It's the perfect solution but it would require hard work
  and dedication, while regression is a serious risk.

My personal preferences goes to the first option: loginfo isn't a bitch to
maintain (I'll gladly do it) and running a few more mailinglists won't be a
disaster either, especially not because this change will safe tons of
bandwidth for all involved.

I'd like to suggest making a relatively small change first: seperate the
kde-i18n e-mails. I'm willing to bet the majority of kde-cvs readers already
have a procmail or KMail rule to get rid of these ASAP and it wouldn't hurt
putting those on a seperate mailinglist (and not keep them on the regular
kde-cvs).

On the long-run I think a module-based seperation is a decent
compromise. It works for discussion, after all. I'm on kde-games-devel, not
kmail-devel, so to me it would be perfectly logical to be on kde-games-cvs
and not on kmail-cvs.

Rob
-- 
Rob Kaper     | "They that can give up essential liberty to obtain a little
cap at capsi.com | temporary safety deserve neither liberty nor safety."
www.capsi.com | - Benjamin Franklin, Historical Review of Pennsylvania, 1759
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030909/aa829c3e/attachment.sig>