Re: contrib vs. gborg/pgfoundry for replication solutions

From: Rod Taylor <pg(at)rbt(dot)ca>
To: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
Cc: Barry Lind <blind(at)xythos(dot)com>, Kris Jurka <books(at)ejurka(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: contrib vs. gborg/pgfoundry for replication solutions
Date: 2004-04-23 15:02:00
Message-ID: 1082732519.95625.70.camel@jester
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 2004-04-22 at 23:05, Robert Treat wrote:
> On Thursday 22 April 2004 13:55, Barry Lind wrote:
> > I think the solution lies in improving www.postgresql.org. At the end
> > of the day it doesn't matter where source code lives, what matters is
> > can people find what they are expecting. Given we know what people are
> > looking for, that should be front and center on the web site and the ftp
> > sites.

> But of course that solution always stalls out when it comes down to picking
> which projects get the special treatment of direct links from the main
> website and which ones stay out of the spotlight. With JDBC you might make

Most end users don't care if they can choose between 20 administration
interfaces. They want to know which one works the best and just use
that.

Guidelines:

1. Must be fully functional with new release of PostgreSQL on day of
PostgreSQL release -- all features. (Admin programs should know how to
create and manage all objects).

2. Must function across a majority of platforms that PostgreSQL
supports.

3. Must be available for free. Something we could *and will* distribute
via CD or could be installed by default. Likewise, source code must be
available to ensure it does not become discontinued.

4. Must be high quality -- equivalent to that of PostgreSQL itself.

5. It should be something that a company selling PostgreSQL support
would be willing to take on.

6. Must have demonstrated the above prior to inclusion on the download
page (gone through a full cycle).

7. They must be willing to change the name to something generic. I.e.
PostgreSQL Administration Interface or PostgreSQL Java Connector.

In other-words, they need to be willing to be a part of the larger
PostgreSQL community. If someone thinks that the JDBC drivers are
broken, the JDBC folks should be open to debate on how to solve the
issues or otherwise argue that there are no problems. Same as how
PostgreSQL itself works.

I really don't see this as being any different than deciding which
buffer strategy or website style to use. One is better in some way so it
becomes a part of the system.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Cramer 2004-04-23 15:07:20 Re: [HACKERS] What can we learn from MySQL?
Previous Message Thomas Swan 2004-04-23 15:00:06 Re: [HACKERS] What can we learn from MySQL?