Re: contrib vs. gborg/pgfoundry for replication solutions

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 Berkus
Aglio Database Solutions
San Francisco