From: | Rod Taylor <pg(at)rbt(dot)ca> |
---|---|
To: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
Cc: | "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-22 01:00:30 |
Message-ID: | 1082595630.80320.184.camel@jester |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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.
I think Gnome (and KDE) have the right idea. Several independent small
projects that once or twice a year get together and have a big release.
We could co-ordinate a set of projects (phppgadmin, pgadmin, slony,
jdbc, odbc, etc. etc.) to make a release on the same day as PostgreSQL.
We then setup several 'meta' packages. For example, PostgreSQL-lite
might be just the core. PostgreSQL-Advanced might include jdbc, pgadmin,
slony, tsearch, postgis and everything in postgresql-lite.
Those who know what they want would be free to install the individual
packages just like with Gnome you can install epiphany and it'll pull in
everything needed for it without any extras.
I suppose one trick is allowing things like Postgis to be compiled
without requiring the source code to be around -- although I suppose we
could suggest a postgresql-headers package which Mozilla did that for a
while.
From | Date | Subject | |
---|---|---|---|
Next Message | Marc G. Fournier | 2004-04-22 01:29:48 | Re: contrib vs. gborg/pgfoundry for replication solutions |
Previous Message | Jan Wieck | 2004-04-21 23:54:38 | Re: contrib vs. gborg/pgfoundry for replication solutions |