W3C home > Mailing lists > Public > www-rdf-interest@w3.org > March 2001

Re: Problem with the list?

From: Uche Ogbuji <uche.ogbuji@fourthought.com>
Date: Tue, 13 Mar 2001 08:25:26 -0700
Message-Id: <200103131525.IAA02194@localhost.localdomain>
To: "Ralph R. Swick" <swick@w3.org>
cc: www-rdf-interest@w3.org
> At 07:32 AM 3/13/2001 -0700, Uche Ogbuji wrote:

> >  The Net burps too frequently for that IMO.  I know that the mailman 
> >list admin software sets a configurable number of bounces after which it 
> >notifies the admin, which would allow that admin to check on things before 
> >dropping the subscriber.
> No one at W3C has time to devote to "checking on things"
> before telling the robot it's ok to drop a subscriber to a big
> list such as www-rdf-interest.   (There are presently 467
> addresses on this distribution list.)  Especially if this means
> tracking bounces for, say, 24 hours, before taking remedial
> action.

I guess it's a question of subscriber base.  I am co-admin on about five 
mailing list, all of which combined have perhaps 400 subscribers.  So I don't 
deal with the size subscriber base you do, but I must say that I don't think I 
get a mailman human intervention event more often than every 2 months or so.  
I'm pretty sure the last time an address was referred to me for excessive 
bounces was Octoberish.

In general, mailman is an absolute breeze to manage, and is *very* intelligent 
in its decisions.  Based on the consistent problems I have with majordomo and, 
I guess, SmartList MLs, I wonder why so many list admins stick with seemingly 
unfriendly technology.

> >  in a high-traffic period, a 
> >30-second network glitch could easily lead to 4 bounces.
> yes, but what number *would* be adequate?  I suppose
> a time-based threshold would improve matters.  I'll suggest
> this to our systems team.  I'm not optimistic for a quick change.

Time-based would be nice.  No big deal if it takes a while to get to it: I can 
deal with being unsubscribed every 4-5 months as long as my re-subscription 
effort actually succeeds.

Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python
Received on Tuesday, 13 March 2001 10:25:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:29 UTC