A maze of twisty mailing lists all the same

From: Greg Stark <stark(at)mit(dot)edu>
To: "<pgsql-hackers(at)postgresql(dot)org>" <pgsql-hackers(at)postgresql(dot)org>
Subject: A maze of twisty mailing lists all the same
Date: 2010-04-08 05:11:00
Message-ID: z2j407d949e1004072211ga3a62d9em64d0b4ef18fed18e@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I've often said in the past that we have too many mailing lists with
overlapping and vague charters. I submit the following thread as
evidence that this causes real problems.

http://archives.postgresql.org/message-id/g2o4b46b5f01004010610ib8625426uae6ee90ac1435ba1@mail.gmail.com

Because the poster chose to send it to pgsql-admin instead of
pgsql-general (or pgsql-bugs) very few of the usual suspects had a
chance to see it. 7 days later a question about a rather serious
database corruption problem had no responses. I've never understand
what the point of pgsql-admin is; just about every question posted is
an "admin" question of some sort.

Likewise I don't think we should have pgsql-performance or pgsql-sql
or pgsql-novice -- any thread appropriate for any of these would be
better served by sending it to pgsql-general anyways (with the
exception of pgsql-performance which has a weird combination of hacker
threads and user performance tuning threads). Sending threads to
pgsql-general would get more eyes on them and would avoid a lot of the
cross-posting headaches. What would someone subscribed to one of these
lists but not pgsql-general get anyways but some random sample of
threads that might be vaguely performance or admin related. They would
still miss most of the administration and performance questions and
discussions which happen on -general and -hackers as appropriate.

--
greg

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2010-04-08 05:17:02 Re: A maze of twisty mailing lists all the same
Previous Message Brendan Jurd 2010-04-08 03:56:33 Re: FM suffix in to_char Y/YY/YYY still screwy