Re: contrib vs. gborg/pgfoundry for replication solutions

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Joe Conway <mail(at)joeconway(dot)com>, josh(at)agliodbs(dot)com, Jan Wieck <JanWieck(at)Yahoo(dot)com>, Rod Taylor <pg(at)rbt(dot)ca>, "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>, Scott Marlowe <scott(dot)marlowe(at)ihs(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: contrib vs. gborg/pgfoundry for replication solutions
Date: 2004-04-23 03:28:46
Message-ID: 200404230328.i3N3SkM27326@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Treat 2004-04-23 03:50:13 Re: pg_encoding not needed anymore
Previous Message Marc G. Fournier 2004-04-23 03:27:25 Re: contrib vs. gborg/pgfoundry for replication solutions