Skip site navigation (1) Skip section navigation (2)

Re: Mailing List Question

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: lockhart(at)fourpalms(dot)org
Cc: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>,"Marc G(dot) Fournier" <scrappy(at)hub(dot)org>,Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Mailing List Question
Date: 2002-03-28 05:05:22
Message-ID: 23009.1017291922@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Thomas Lockhart <lockhart(at)fourpalms(dot)org> writes:
> imho we should disable *any* special handling of posts to the mailing
> lists.

It would be interesting to try that for awhile and see if the cure is
worse than the disease or not.  How many clueless "uns*bscr*be" requests
will hit the lists if there are no filters?

I suspect that we need to settle on a happy medium.  What we've got now
seems to be very far over on the "filter 'em first and sort it out later"
end of the spectrum.  The "no filter at all" end of the spectrum has its
own obvious drawbacks (though I've used it successfully for >10 years
on another mailing list that I run).

If we could reduce the occurrence of false blocks by a factor of 10 or
100, at the price of maybe one or two misdirected administrative
requests per month hitting the lists, I'd consider it a great tradeoff;
and I'd have to think that it'd reduce Marc's moderation workload a lot,
too.  Maybe that's an overoptimistic assessment --- Marc probably knows
better than any of the rest of us what fraction of messages stopped by
the filters are good traffic and what are not.  But it sure seems like
the system is not optimally tuned at the moment.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Christopher Kings-LynneDate: 2002-03-28 06:03:26
Subject: Procedures returning row sources
Previous:From: Thomas LockhartDate: 2002-03-28 04:42:23
Subject: Re: Mailing List Question

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group