Re: contrib vs. gborg/pgfoundry for replication solutions - Mailing list pgsql-hackers

From Rod Taylor
Subject Re: contrib vs. gborg/pgfoundry for replication solutions
Date
Msg-id 1082732519.95625.70.camel@jester
Whole thread Raw
In response to Re: contrib vs. gborg/pgfoundry for replication solutions  (Robert Treat <xzilla@users.sourceforge.net>)
Responses Re: contrib vs. gborg/pgfoundry for replication solutions
List 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.



pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: What can we learn from MySQL?
Next
From: Thomas Swan
Date:
Subject: Re: What can we learn from MySQL?