Re: contrib vs. gborg/pgfoundry for replication solutions

Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073