[Savannah-hackers-public] [gnu.org #274391] Re: Mailman upgrade

[Joshua Ginsberg via RT]

It is our intention to upgrade to mailman 2.1.7 upon completion of the
project, which has the mass discard feature. When we do the upgrade, we
will trove the archives and held message queues and push the messages
through a spam control system. Items tagged as spam will be put into a
quarantine for list administrators to sift through, and the remainder
will be discarded.

-jag

> [beuc - Thu Feb 09 17:32:13 2006]:
> 
> Sysadmin,
> 
> Karl and I have had a look at the Mailman held messages.
> 
> We have a growing list of around 120,000 messages, all in the same
> directory.
> 
> I state it, so you keep that in mind for the upcoming mail system. For
> example, Karl mentioned a Mailman feature to clean-up old requests,
> but nor Sarge not Fedora 4 include it yet.
> 
> What's your point on this? Do you already have something in mind to
> cope with all those held messages? Do you think this currently
> significantly impact performances?
> 
> 
> More details now - a direct reply to Karl :)
> 
> On Mon, Feb 06, 2006 at 01:19:55PM -0600, Karl Berry wrote:
> > On the other hand, just rm'ing the files didn't work well either; then
> > the msgs were still visible in the pending queue, albeit with some
> > information missing.  However, doing that will at least clean up the
> > directory, so maybe it is the way to go for now.
> 
> I did so for removed mailing lists (~500 msgs), and also removed held
> messages under an old format (files in *.txt) back from 2002 (~6000
> msgs). More precisions in the ChangeLog.
> 
> 
> I also noticed that you see the "pending queue [...] with some
> information missing" only once. After that, Mailman regenerates
> request.pck; so a little curl
> http://lists.gnu.org/mailman/admindb/listname -F adminpw=***** per
> list would clean the list of messages.
> 
> Instead of (or in addition to) setting up a clean-up cron-job (I hope
> the next mailsystem will use that recent version of Maiman), an
> alternative would be to cope with the "top-ten", which accounts for
> around around 50% of all messages:
> 
>    1017 adhoc
>    1099 alcovebook-dev
>    1116 fsfe-portugal
>    1162 dmca-activists
>    1259 gnump3d-devel
>    1311 bug-gnu-chess
>    1634 a2ps
>    2426 info-gnu-fortran
>    2484 cons-discuss
>   11556 bug-vcdimager
>   29634 info-cvs
> 
> 
> Last 6 months of all held messages represent more than half of all
> held messages actually, so maybe it's not as useful as I though wrt
> performances - we always get thousands of held messages at once,
> unless we clean messages earlier than after 6 months.
> 
> 
> 
-- 
Joshua Ginsberg <address@hidden>
Free Software Foundation - Senior Systems Administrator