Re: contrib vs. gborg/pgfoundry for replication solutions - Mailing list pgsql-hackers

From Karel Zak
Subject Re: contrib vs. gborg/pgfoundry for replication solutions
Date
Msg-id 20040422064047.GE2953@zf.jcu.cz
Whole thread Raw
In response to Re: contrib vs. gborg/pgfoundry for replication solutions  (Oleg Bartunov <oleg@sai.msu.su>)
List 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 by date:

Previous
From: Joe Conway
Date:
Subject: Re: contrib vs. gborg/pgfoundry for replication solutions
Next
From: Rod Taylor
Date:
Subject: Re: contrib vs. gborg/pgfoundry for replication solutions