
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.marlowe@ihs.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
> 

Thu, 22 Apr 2004 00:00:16 +0200
"Magnus Hagander" <mha@sollentuna.net>
Re: contrib vs. gborg/pgfoundry for replication solutions
On Thu, 22 Apr 2004, Magnus Hagander wrote:

>
> 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 see no reaosn why projects can't be mirrored into the main ftp server,
and brought through the mirrors ...

> 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.

ftp://gborg.postgresql.org/pub - ls everything is listed there ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Wed, 21 Apr 2004 20:21:15 -0300 (ADT)
"Marc G. Fournier" <scrappy@postgresql.org>
Re: contrib vs. gborg/pgfoundry for replication solutions
Magnus Hagander wrote:
> 
> 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.

I was thinking about CPAN.  They have download stuff, but it installs
very easily.  I wonder if we should allow gborg projects to interface to
our configure output in a way that makes it easier for them to be
installed.

The gborg is easy for development and releasing, but loses in the
easy-of-use category sometimes.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Wed, 21 Apr 2004 21:48:12 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: contrib vs. gborg/pgfoundry for replication solutions
On Wed, 21 Apr 2004, Bruce Momjian wrote:

> I was thinking about CPAN.  They have download stuff, but it installs
> very easily.  I wonder if we should allow gborg projects to interface to
> our configure output in a way that makes it easier for them to be
> installed.

No, because again that requires you to download a large tar ball just to
get the build environment?

> The gborg is easy for development and releasing, but loses in the
> easy-of-use category sometimes.

So, what we *should* be looking at it some sort of howto on how to setup
an autoconf environment ... the basics aren't too hard, its only when you
get into the more complicated stuff that only *large* projects tend to get
into that it gets particulary confusing ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Wed, 21 Apr 2004 23:27:07 -0300 (ADT)
"Marc G. Fournier" <scrappy@postgresql.org>
Re: contrib vs. gborg/pgfoundry for replication solutions
Marc G. Fournier wrote:
> On Wed, 21 Apr 2004, Bruce Momjian wrote:
> 
> > I was thinking about CPAN.  They have download stuff, but it installs
> > very easily.  I wonder if we should allow gborg projects to interface to
> > our configure output in a way that makes it easier for them to be
> > installed.
> 
> No, because again that requires you to download a large tar ball just to
> get the build environment?
> 
> > The gborg is easy for development and releasing, but loses in the
> > easy-of-use category sometimes.
> 
> So, what we *should* be looking at it some sort of howto on how to setup
> an autoconf environment ... the basics aren't too hard, its only when you
> get into the more complicated stuff that only *large* projects tend to get
> into that it gets particulary confusing ...

There are only a few PostgreSQL developers who can do it, so what are
the odds that a single guy who maintains a plugin is going to be able to
do it.  And you can say it is easy, but it just takes one complex
problem to hit you, and with PostgreSQL, and all the shared lib stuff
and dynamic loading, lots of it is complex.

Let's face it, unbundling is great for release efficiency, but terrible
for ease-of-use, and let me also tell you that that is where MySQL
shines and is perhaps taking new users from us.  No secret there.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Wed, 21 Apr 2004 22:44:33 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: contrib vs. gborg/pgfoundry for replication solutions
On Wed, 21 Apr 2004, Bruce Momjian wrote:

> There are only a few PostgreSQL developers who can do it, so what are
> the odds that a single guy who maintains a plugin is going to be able to
> do it.  And you can say it is easy, but it just takes one complex
> problem to hit you, and with PostgreSQL, and all the shared lib stuff
> and dynamic loading, lots of it is complex.

So, put together a developers kit ... you'd need, what, a half dozen files
to bootstrap a project with?  configure.in, Makefile.in, a README file
with the basics on what needs to be modified in Makefile.in, the
src/template directory ...

If you are looking for a problem to solve, make it easier for developers
to setup a proper build environment, don't punish end-users to giving them
a bigger package to download


----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Wed, 21 Apr 2004 23:57:24 -0300 (ADT)
"Marc G. Fournier" <scrappy@postgresql.org>
Re: contrib vs. gborg/pgfoundry for replication solutions
Marc G. Fournier wrote:
> On Wed, 21 Apr 2004, Bruce Momjian wrote:
> 
> > There are only a few PostgreSQL developers who can do it, so what are
> > the odds that a single guy who maintains a plugin is going to be able to
> > do it.  And you can say it is easy, but it just takes one complex
> > problem to hit you, and with PostgreSQL, and all the shared lib stuff
> > and dynamic loading, lots of it is complex.
> 
> So, put together a developers kit ... you'd need, what, a half dozen files
> to bootstrap a project with?  configure.in, Makefile.in, a README file
> with the basics on what needs to be modified in Makefile.in, the
> src/template directory ...
> 
> If you are looking for a problem to solve, make it easier for developers
> to setup a proper build environment, don't punish end-users to giving them
> a bigger package to download

Download (100% reliable to fix problem) vs. my time to build kit --- I
pick download.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Wed, 21 Apr 2004 23:12:08 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: contrib vs. gborg/pgfoundry for replication solutions
Bruce Momjian wrote:
> I was thinking about CPAN.  They have download stuff, but it installs
> very easily.  I wonder if we should allow gborg projects to interface to
> our configure output in a way that makes it easier for them to be
> installed.

Now that idea I like. The R project also has something similar that 
allows a standard R command to download, compile, and install their 
equivalent to contrib packages. They even have an automated system of 
testing the contributed packages to ensure they work. If the package 
doesn't meet certain standards, it is automatically dropped from the 
link list on the download page. See:
http://cran.r-project.org/doc/manuals/R-exts.pdf
if you're interested. Very impressive, but also a huge amount of work to 
set up.

> The gborg is easy for development and releasing, but loses in the
> easy-of-use category sometimes.

I agree.

Joe


Wed, 21 Apr 2004 21:25:01 -0700
Joe Conway <mail@joeconway.com>
Re: contrib vs. gborg/pgfoundry for replication solutions
Joe Conway wrote:
> Bruce Momjian wrote:
> > I was thinking about CPAN.  They have download stuff, but it installs
> > very easily.  I wonder if we should allow gborg projects to interface to
> > our configure output in a way that makes it easier for them to be
> > installed.
> 
> Now that idea I like. The R project also has something similar that 
> allows a standard R command to download, compile, and install their 
> equivalent to contrib packages. They even have an automated system of 
> testing the contributed packages to ensure they work. If the package 
> doesn't meet certain standards, it is automatically dropped from the 
> link list on the download page. See:
> http://cran.r-project.org/doc/manuals/R-exts.pdf
> if you're interested. Very impressive, but also a huge amount of work to 
> set up.
> 
> > The gborg is easy for development and releasing, but loses in the
> > easy-of-use category sometimes.
> 
> I agree.

I am thinking they could untar into a directory under pgsgl/ or have a
way to point to a 'configure'-run source tree and pull values from
there.

If you include pg_config.h, or use Makefile.global, you have almost
everything you need to compile your own, including flags, configure
checks, and the location of the installation directory.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Thu, 22 Apr 2004 00:29:36 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: contrib vs. gborg/pgfoundry for replication solutions
Bruce Momjian wrote:
> I am thinking they could untar into a directory under pgsgl/ or have a
> way to point to a 'configure'-run source tree and pull values from
> there.

> If you include pg_config.h, or use Makefile.global, you have almost
> everything you need to compile your own, including flags, configure
> checks, and the location of the installation directory.

How hard would it be to have the individual cvs projects such that they 
could be checked out all in one shot?

I'm thinking that if it was easy enough to maintain an up-to-date cvs 
copy for all the individual projects, then it would be easy to grep the 
entire mess when making backend changes. That way at least you could 
determine the extent of the impact when making backend changes. And 
since they are still individual projects, you don't need to get them all 
if you're not interested.

Joe


Wed, 21 Apr 2004 21:43:36 -0700
Joe Conway <mail@joeconway.com>
Re: contrib vs. gborg/pgfoundry for replication solutions
On Thu, Apr 22, 2004 at 12:29:36AM -0400, Bruce Momjian wrote:

> I am thinking they could untar into a directory under pgsgl/ or have a
> way to point to a 'configure'-run source tree and pull values from
> there.
> 
> If you include pg_config.h, or use Makefile.global, you have almost
> everything you need to compile your own, including flags, configure
> checks, and the location of the installation directory.

That would work only if they compiled the source themselves, as opposed
to using a binary package (which is very common).  I'm not sure if
installing the postgresql-dev or postgresql-devel package would be
enough.

If not, maybe pg_config could provide all the necessary info ...

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
Hi! I'm a .signature virus!
cp me into your .signature file to help me spread!

Thu, 22 Apr 2004 00:56:15 -0400
Alvaro Herrera <alvherre@dcc.uchile.cl>
Re: contrib vs. gborg/pgfoundry for replication solutions
Alvaro Herrera wrote:

>On Thu, Apr 22, 2004 at 12:29:36AM -0400, Bruce Momjian wrote:
>
>  
>
>>I am thinking they could untar into a directory under pgsgl/ or have a
>>way to point to a 'configure'-run source tree and pull values from
>>there.
>>
>>If you include pg_config.h, or use Makefile.global, you have almost
>>everything you need to compile your own, including flags, configure
>>checks, and the location of the installation directory.
>>    
>>
>
>That would work only if they compiled the source themselves, as opposed
>to using a binary package (which is very common).  I'm not sure if
>installing the postgresql-dev or postgresql-devel package would be
>enough.
>
>If not, maybe pg_config could provide all the necessary info ...
>
>  
>

The pieces of the current build environment, used or possibly required 
by any contrib module (including scripts like mkldexport.sh and such) 
whold have to be installed under $datadir/devel or the like and made 
location independent. That's all.


Jan

-- 

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #




Thu, 22 Apr 2004 08:55:22 -0400
Jan Wieck <JanWieck@Yahoo.com>
Re: contrib vs. gborg/pgfoundry for replication solutions
On Wed, 21 Apr 2004, Bruce Momjian wrote:

> Marc G. Fournier wrote:
> > On Wed, 21 Apr 2004, Bruce Momjian wrote:
> >
> > > There are only a few PostgreSQL developers who can do it, so what are
> > > the odds that a single guy who maintains a plugin is going to be able to
> > > do it.  And you can say it is easy, but it just takes one complex
> > > problem to hit you, and with PostgreSQL, and all the shared lib stuff
> > > and dynamic loading, lots of it is complex.
> >
> > So, put together a developers kit ... you'd need, what, a half dozen files
> > to bootstrap a project with?  configure.in, Makefile.in, a README file
> > with the basics on what needs to be modified in Makefile.in, the
> > src/template directory ...
> >
> > If you are looking for a problem to solve, make it easier for developers
> > to setup a proper build environment, don't punish end-users to giving them
> > a bigger package to download
>
> Download (100% reliable to fix problem) vs. my time to build kit --- I
> pick download.

Right, but you don't count ... you aren't an end-user

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Thu, 22 Apr 2004 21:06:58 -0300 (ADT)
"Marc G. Fournier" <scrappy@postgresql.org>
Re: contrib vs. gborg/pgfoundry for replication solutions
Marc G. Fournier wrote:
> On Wed, 21 Apr 2004, Bruce Momjian wrote:
> 
> > Marc G. Fournier wrote:
> > > On Wed, 21 Apr 2004, Bruce Momjian wrote:
> > >
> > > > There are only a few PostgreSQL developers who can do it, so what are
> > > > the odds that a single guy who maintains a plugin is going to be able to
> > > > do it.  And you can say it is easy, but it just takes one complex
> > > > problem to hit you, and with PostgreSQL, and all the shared lib stuff
> > > > and dynamic loading, lots of it is complex.
> > >
> > > So, put together a developers kit ... you'd need, what, a half dozen files
> > > to bootstrap a project with?  configure.in, Makefile.in, a README file
> > > with the basics on what needs to be modified in Makefile.in, the
> > > src/template directory ...
> > >
> > > If you are looking for a problem to solve, make it easier for developers
> > > to setup a proper build environment, don't punish end-users to giving them
> > > a bigger package to download
> >
> > Download (100% reliable to fix problem) vs. my time to build kit --- I
> > pick download.
> 
> Right, but you don't count ... you aren't an end-user

True, but what the end users get is nothing because I don't have the
time.  No configure, no build environment, very user-unfriendly.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Thu, 22 Apr 2004 20:28:31 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: contrib vs. gborg/pgfoundry for replication solutions
Bruce Momjian wrote:
> Marc G. Fournier wrote:
>>Right, but you don't count ... you aren't an end-user
> 
> True, but what the end users get is nothing because I don't have the
> time.  No configure, no build environment, very user-unfriendly.
> 

Exactly.

Joe

Thu, 22 Apr 2004 18:23:50 -0700
Joe Conway <mail@joeconway.com>
Re: contrib vs. gborg/pgfoundry for replication solutions