Re: contrib vs. gborg/pgfoundry for replication solutions

IMHO it's not all that important where the source is developed (core
cvs, gborg etc) - whichever suits the development/release model best
shuold be used (meaning inside core only if it should be released on the
very same schedule as the main backend only).

What is more important is the exposure of the released versions. I think
it should be possible (and fairly easy) for projects developed outside
the core to get included in the "official download page", meaning go on
the ftp site and mirrors. Today it seems ODBC and pgadmin3 go there, but
pretty much nothing else (not even JDBC?). Perhaps a good structure
there would allow more proejcts to get that kind of exposure, and be
easier to find.

I quite often get people who claim "there is no this or that" for pgsql
when it's on gborg - simply becauase they didn't find it on the ftp
site. If you go looking, you'll find it on gborg, but if you don't know
where to look it can be hard. Especially for newcomers.

//Magnus

> -----Original Message-----
> From: scott.marlowe [mailto:scott(dot)marlowe(at)ihs(dot)com]
> Sent: Wednesday, April 21, 2004 10:03 PM
> To: Joshua D. Drake
> Cc: Jan Wieck; PostgreSQL-development
> Subject: Re: [HACKERS] contrib vs. gborg/pgfoundry for
> replication solutions
>
>
> I almost agree, but I think things that are being actively
> developed to
> eventually move into the backend, like autovacuum or slony-I
> should be in
> contrib. Things that aren't destined for backend integration
> should be
> removed though, like pgbench or dblink or whatnot.
>
> On Wed, 21 Apr 2004, Joshua D. Drake wrote:
>
> > Hello,
> >
> > My personal opinion is that contrib should be removed entirely. Just
> > have a contrib.txt that says all contrib modules are at
> pgfoundry or
> > whatever.
> >
> > Sincerely,
> >
> > Joshua D. Drake
> >
> >
> > Jan Wieck wrote:
> >
> > > Taking into account that quite a few people have
> repeatedly stated
> > > that
> > > the components in contrib are considered more
> supported/recommended than
> > > similar solutions found on gborg or any other external
> site, I suggest
> > > we move the projects dbmirror and dblink to gborg. The
> rserv contrib
> > > module seems to me to be an early Perl prototype of
> erserver, nobody is
> > > working on any more. I suggest we drop that entirely.
> > >
> > > Comments/alternatives?
> > >
> > >
> > > Jan
> > >
> >
> > ---------------------------(end of
> > broadcast)---------------------------
> > TIP 8: explain analyze is your friend
> >
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>