Re: contrib vs. gborg/pgfoundry for replication solutions

Поиск
Список
Период
Сортировка
От Karel Zak
Тема Re: contrib vs. gborg/pgfoundry for replication solutions
Дата
Msg-id 20040422064047.GE2953@zf.jcu.cz
обсуждение исходный текст
Ответ на Re: contrib vs. gborg/pgfoundry for replication solutions  (Oleg Bartunov <oleg@sai.msu.su>)
Список pgsql-hackers
On Thu, Apr 22, 2004 at 12:41:28AM +0400, Oleg Bartunov wrote:
> The problem with moving all contribs to gborg is that sometimes it's
> required to change many modules, for example, because of changing
> GiST interface. Tom saves a lot of working for contrib authors, when he
> change code in core. I'm not sure, gborg would provide easy access for
> such kind of things. tsearch2, particularly, is maintained in pgsql CVS.
Agree. The basic  argue for removing  something from contrib  should bethat nobody  maintain a module  or that maintain
it in the  contrib isdifficult.
 
Other problem  -- now  maintainers of distribution  PostgreSQL packages(Debian/RH/...) make packages from the  contrib
tree.Are you sure theywill search  something on sourceforge/gborg and  make separate packegesfor each small script? How
theywill detect what is good for packaging?The contrib  tree is  basic selection of  interesting small  thigs
fromPostgreSQLworld.
 
   Karel

-- Karel Zak  <zakkr@zf.jcu.cz>http://home.zf.jcu.cz/~zakkr/


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

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: contrib vs. gborg/pgfoundry for replication solutions
Следующее
От: Rod Taylor
Дата:
Сообщение: Re: contrib vs. gborg/pgfoundry for replication solutions