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

From Josh Berkus
Subject Re: contrib vs. gborg/pgfoundry for replication solutions
Date
Msg-id 200404221224.31427.josh@agliodbs.com
Whole thread Raw
In response to Re: contrib vs. gborg/pgfoundry for replication solutions  (Jan Wieck <JanWieck@Yahoo.com>)
Responses Re: contrib vs. gborg/pgfoundry for replication solutions  (Joe Conway <mail@joeconway.com>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: License question
Next
From: Tom Lane
Date:
Subject: Re: valgrind errors