Re: contrib vs. gborg/pgfoundry for replication solutions

Поиск
Список
Период
Сортировка
От Marc G. Fournier
Тема Re: contrib vs. gborg/pgfoundry for replication solutions
Дата
Msg-id 20040421200715.Y32445@ganymede.hub.org
обсуждение исходный текст
Ответ на Re: contrib vs. gborg/pgfoundry for replication solutions  ("scott.marlowe" <scott.marlowe@ihs.com>)
Ответы Re: contrib vs. gborg/pgfoundry for replication solutions  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: contrib vs. gborg/pgfoundry for replication solutions  (Jan Wieck <JanWieck@Yahoo.com>)
Список pgsql-hackers
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?

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?

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

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Marc G. Fournier"
Дата:
Сообщение: Re: contrib vs. gborg/pgfoundry for replication solutions
Следующее
От: "Marc G. Fournier"
Дата:
Сообщение: Re: contrib vs. gborg/pgfoundry for replication solutions