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

From Bruce Momjian
Subject Re: contrib vs. gborg/pgfoundry for replication solutions
Date
Msg-id 200404230328.i3N3SkM27326@candle.pha.pa.us
Whole thread Raw
In response to Re: contrib vs. gborg/pgfoundry for replication solutions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: contrib vs. gborg/pgfoundry for replication solutions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
> > As I've said on other parts of this thread, my concern with moving 
> > everything to gborg/pgFoundry is that it raises the bar in terms of 
> > difficulty if we expect every individual project to develop their own 
> > infrastructure.
> 
> I think that's exactly right.  It may be okay for the core project to
> decide these little side projects are outside our responsibility ---
> but what we had better take responsibility for is a framework within
> which it's easy to maintain little side projects.  The cost of that
> infrastructure is too high to expect the little projects to handle it
> individually.
> 
> > What we need to really make that work is to provide an 
> > infrastructure similar to Perl's CPAN or the R project's CRAN.
> 
> There's more than one issue.  CPAN makes it easy for end users to find
> and install little projects.  We need that, but we also need to make it
> easy for programmers to build and maintain those projects.  There was
> some speculation earlier in the thread about whether the existing
> contrib framework would do as a basis --- I don't know if it can be made
> to work, or if it's sufficient, but it might do.  In any case we can't
> just toss contrib modules over the side and expect that good things will
> happen to them when they can't even be built outside the main tree.
> The effort to fix that on a retail basis would alone guarantee that
> they will be stillborn projects.

What if we create a build/ directory as part of install that
pg_config.h, Makefile.global, etc, anything a plugin would need, and
install it by default.  Then, if we give folks an easy way to access
them from their own apps and Makefiles, it would solve most of the
problems.

--  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,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: Re: contrib vs. gborg/pgfoundry for replication solutions
Next
From: Robert Treat
Date:
Subject: Re: pg_encoding not needed anymore