--4Kq+wHeKEs1nwG7z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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@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
--=20
Rob Kaper     | "They that can give up essential liberty to obtain a little
cap@capsi.com | temporary safety deserve neither liberty nor safety."
www.capsi.com | - Benjamin Franklin, Historical Review of Pennsylvania, 1759

--4Kq+wHeKEs1nwG7z
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/XdH8tppIl2G1SjcRAsSHAJwKJGXGk2/ttnjufBsld1rNnYMk5gCgvdcr
OeuS7618AQUip6zHyzS6iLc=
=zTXG
-----END PGP SIGNATURE-----

--4Kq+wHeKEs1nwG7z--