Re: contrib vs. gborg/pgfoundry for replication solutions

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: contrib vs. gborg/pgfoundry for replication solutions
Дата
Msg-id 200404221224.31427.josh@agliodbs.com
обсуждение исходный текст
Ответ на Re: contrib vs. gborg/pgfoundry for replication solutions  (Jan Wieck <JanWieck@Yahoo.com>)
Ответы Re: contrib vs. gborg/pgfoundry for replication solutions  (Joe Conway <mail@joeconway.com>)
Список pgsql-hackers
Jan,

> Josh, is there anything that remotely sounds like this in the new system 
> you're setting up?

Not AFAIK.     I'm really not a CVS person (as you may have gathered), but I'm 
under the impression that GForge is a pretty "dumb" user of CVS.

As far as I'm concerned, what you've suggested is what we should be aiming 
toward -- and is a reason to consider Subversion or ARCH if that's what it 
takes.   We *do* need CPAN-like plugabbility, but unfortunately, I am too 
much of a collaboration neophyte to suggest how to construct one.

The reason to shrink contrib, from my perspective, is that we have too many 
associated projects to include them *all* in contrib -- we'd be talking a 
125MB download.    Many of these packages (the GUIs, for example) are 
redundant for any single user.  And, if we continue to be successful as an 
OSS project, we can expect the number of these packages to grow.

Which packages do and do not get included in /contrib has been a very 
arbitrary process to date -- mostly having to do with convenience and how 
involved the developer is on this list.   I started thinking of this when 
JDBC was moved out of contrib, over some protests, and started thinking,"why 
should DBMirror be in contrib and JDBC not?  Why is Tsearch in contrib and 
guid not?"

Overally, contrib continues to form a sort of "stamp of approval" that add-ins 
are "official" and part of PostgreSQL, while the stuff on GBorg is not.   
This is unfair to the very good and userful projects which are on Gborg, 
particularly considering the contrib items (like tsearch1 or postgres-r) 
which are depreciated even by thier original owners!

We can't have *everything* in contrib -- the top 5 GUIs alone would triple the 
size of our downloads.   So we need to move in the opposite direction -- 
putting more stuff in pgFoundry, and letting packagers know that they should 
package and include all "mature" projects on pgFoundry if they can.  (our 
earlier discussion proved that this list cannot realistically designate 
"approved" vs. "unapproved" projects).

-- 
-Josh BerkusAglio Database SolutionsSan Francisco



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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: License question
Следующее
От: Tom Lane
Дата:
Сообщение: Re: valgrind errors