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

Re: Why the current setup of pgsql.* and comp.databases.postresql.general are BROKEN

From: Woodchuck Bill <bwr607(at)hotmail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Why the current setup of pgsql.* and comp.databases.postresql.general are BROKEN
Date: 2004-11-27 20:14:58
Message-ID: Xns95AE9B0D29C45bswr607h4@130.133.1.4 (view raw or flat)
Thread:
Lists: pgsql-general
Robert McClenon <robert(dot)mcclenon(at)verizon(dot)net> wrote in
news:50lhq0lc6gke02ktt3tvdheir96knd2m6c(at)4ax(dot)com: 

> On 27 Nov 2004 18:32:35 GMT, Woodchuck Bill <bwr607(at)hotmail(dot)com>
> wrote:
> 
>>Robert McClenon <robert(dot)mcclenon(at)verizon(dot)net> wrote in 
>>news:7fahq0dcvpuc8d11k20gscfvrshoslbvk3(at)4ax(dot)com:
>>
>>> However, I will vote NO on the new group, because
>>> it will in my opinion be harmful to good management of the Big
>>> Eight, unless some solution to this misconfiguration is proposed.
>>
>>I will vote "no" on all five of the new groups, unless some serious
>>changes are made in the next RFD. For one, Marc needs to decide which
>>hierarchy he wants to use..comp.* or pgsql.*..NOT BOTH. The groups
>>need to be declared as moderated groups, the annoying e-mail
>>confirmation needs to be dropped, and the entire system needs to be
>>layed out in the next RFD. 
> 
> I don't see a reason for making the groups be moderated.  That would
> solve the asymmetry.  However, I would then want to see the moderation
> plan, and to know whether the moderators understood the subtleties of
> how moderation works in connection with a gateway.  It appears that
> Marc does not understand the subtleties of an unmoderated group and a
> gateway that acts as a robomoderator, but maybe his understanding is
> too subtle for me.

Think about a typical Usenet poster, with a question about PostgreSQL. He 
does a keyword search in his newsreader for "postgresql". The only group 
that comes up is a dead alt.* group, alt.comp.databases.postgresql. He 
subscribes, sees no traffic, unsubscibes. The pgsql.* hierarchy, even if 
his news server carries the groups, does not display in his keyword search 
because "postgresql" does not appear in any of the newsgroup names. He 
tries again in a few months. Five of the comp.* groups pass the CFV and 
they appear in his newsreader during a keyword search. He posts his 
question to *.novice or *.general, and he sees the post appear immediately 
on his server..thus he assumes that the group is not moderated. Then he 
gets that annnoying and confusing e-mail. 

The typical person finding the comp.* postgresql groups, if they pass, will 
have no knowledge that his posts are being redistributed to several 
thousand inboxes via a (moderated) mailing list. Is that ethical 
redistribution of his articles? He does not know that 99 percent of the 
traffic he sees is coming from the mailing list, and that almost none of 
his responses will come from Usenet.

The whole system stinks.

>>The proponent might want to consider distancing his five postgresql
>>comp.* groups in this proposal from the mailing lists enitirely. One
>>of more standalone newsgroups with no connection to the mailing lists
>>might be a better idea, and I would not vote against that.
> 
> That sounds like the best idea.  The pgsql.* hierarchy can continue to
> interface in the current eccentric way with the lists, and one or more
> comp.* newsgroups can stand on their own.

Now that Marc has created his own dedicated hierarchy, and all 29 lists are 
gated to individual groups..picked up by Supernews and soon-to-be 
Stanford..the best thing for the proponent to do from now on is to go back 
to the single group for PostgreSQL..named comp.databases.postgresql..with 
no connection to any of the mailing lists. 

Nice and simple, just like the MySQL proposal on the floor: a single, truly 
unmoderated newsgroup that follows the standard comp.databases.* naming 
convention as opposed to having a cumbersome top-level name like the 
currently proposed comp.databases.postgresql.general.

-- 
Bill

In response to

pgsql-general by date

Next:From: Kenneth TanzerDate: 2004-11-27 20:56:09
Subject: Section 9.6.3.5, Regular Expression Matching Rules
Previous:From: Kamil KaczkowskiDate: 2004-11-27 20:13:17
Subject: Re: row-level deadlock problem

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