Re: contrib vs. gborg/pgfoundry for replication solutions

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>
Cc: "scott(dot)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-21 23:54:38
Message-ID: 408709BE.3080806@Yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Marc G. Fournier wrote:
> On Wed, 21 Apr 2004, scott.marlowe wrote:
>
>> 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.
>
> Slony-I involves no backend integration that I've seen in its docs ...
> Jan? Did I miss something?

Slony-I is intended to be PG version independent as much as possible. It
would rather hurt to move it into contrib. Sure are there backend
dependencies to #ifdef/#else, but for Slony-I this is considered a
strength, not a problem. How else would it be possible to use Slony-I to
do a PostgreSQL major version upgrade of multi-GB databases with only a
few seconds interruption?

>
> As far as stuff like autovacuum, though ... its something that could
> definitely benefit from a seperate release cycle from the main code ...
>
> Has anyone looked at developing an Installer/packaging system so that as
> far as the code is concerned, thing are seperate projects, but for the end
> user ...
>
> The thing is, for how many ppl are seperate packages difficult? I know
> for me, under FreeBSD, I cd to a /usr/ports/databases/pg_autovacuum and
> type 'make install' and its done ... I thought that stuff like Redhat had
> the full screen installer that lists things?

I think most of the current contrib projects are more missing the
advantage version independence would have for the ease of "sitting" in
contrib and having the whole project management around them just done.
Yes, doing your own gborg project costs time. You have to maintain
pages, do your own release cycles with announcement, BETA phase,
tarballs, packaging and all the nine yards. Being in contrib avoids all
that in a very convenient way.

>
> My point is that all of this stuff shouldn't be in the core CVS ... its a
> packaging issue, not a cvs one ...

Exactly.

Jan

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rod Taylor 2004-04-22 01:00:30 Re: contrib vs. gborg/pgfoundry for replication solutions
Previous Message Joshua D. Drake 2004-04-21 23:31:30 Re: contrib vs. gborg/pgfoundry for replication solutions