Re: Postresql RFD version 2.0 Help Wanted. - Mailing list pgsql-general

From Mike Cox
Subject Re: Postresql RFD version 2.0 Help Wanted.
Date
Msg-id 2v4pdkF2gdc9qU1@uni-berlin.de
Whole thread Raw
In response to Postresql RFD version 2.0 Help Wanted.  (Mike Cox <mikecoxlinux@yahoo.com>)
List pgsql-general
Woodchuck Bill wrote:

> Mike Cox <mikecoxlinux@yahoo.com> wrote in news:2v4mbfF2i3beoU1@uni-
> berlin.de:
>
>> Since we have the discussion going, someone mentioned that the group name
>> should be comp.databases.postgresql.  I think this is a good name and I'd
>> like to see what everyone thinks of it.
>
> Much better, especially if you are only proposing a single newsgroup in
> the hierarchy. Use of the word "general" is unnecessary, and cumbersome.
>

My original intention was to make the comp.database.postgresql.* groups
proper members of the "big 8" managed hierarchy.  They are considered
"bogus" currently by many proper News providers because they haven't gone
through RFD and CFV.  I wanted to start slowly and with the most benefitial
group, comp.databases.postgresql.general, and then do the others in
accordance to traffic interest as measured by google groups.

There is resistance in the mailing lists however, even though the groups are
already on usenet and are in the  managed "big 8" name space without RFD
and CFV.

That is why I am now proposing to change it to comp.databases.postresql so
it doesn't clash with the mailing list name space of
comp.databases.postgresql.general.  If others on the
mailing-list/usenet-gateway do want to be proper members of the big 8, then
they should speak up.

There is also the issue of moving the postgresql mailing list/news gateway
to a private namespace like  postgresql.*.  This would be similar to gnu.*
and microsoft.*.  This would solve the problem of the postgresql groups
residing in a managed hierarchy without going through RFD and CFV, which
was the problem I was originally trying to solve.

pgsql-general by date:

Previous
From: Troels Arvin
Date:
Subject: Re: Trying to get postgres to use an index
Next
From: Hunter Hillegas
Date:
Subject: Re: Mass Import/Generate PKs