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

Gary L. Burnore <gburnore@databasix.com> wrote in
news:co8frd$ktk$1@blackhelicopter.databasix.com:

> I'm posting to a USENet group.  I shouldn't be receiving an email from
> the list.  If the groups had been generated as MODERATED newsgroups,
> my post wouldn't hit MY spool, then go to HIS server for some
> approval, later to appear a second time and AFTER I receive this
> STUPID message in email.
>
> Of course, he doesn't CARE.

Just think about how easy it would be for a forging troll to mailbomb
anyone he wanted to by flooding the newsgroup with posts under the victim's
spoofed e-mail address. This system is too vulnerable to abuse. The groups
should be moderated, for one. Second, Marc needs to decide whether he wants
the groups to be in pgsql.*, *or* comp.* ... not both. The lists and gating
methods should all be explained in detail on the final RFD, so they appear
on the CFV.

--
Bill

Robert McClenon <robert.mcclenon@verizon.net> wrote in
news:50lhq0lc6gke02ktt3tvdheir96knd2m6c@4ax.com:

> On 27 Nov 2004 18:32:35 GMT, Woodchuck Bill <bwr607@hotmail.com>
> wrote:
>
>>Robert McClenon <robert.mcclenon@verizon.net> wrote in
>>news:7fahq0dcvpuc8d11k20gscfvrshoslbvk3@4ax.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