Criteria for contrib/ versus gborg? - Mailing list pgsql-hackers

From Andrew Sullivan
Subject Criteria for contrib/ versus gborg?
Date
Msg-id 20030715201934.GF28141@libertyrms.info
Whole thread Raw
Responses Re: Criteria for contrib/ versus gborg?  (Robert Treat <xzilla@users.sourceforge.net>)
Re: Criteria for contrib/ versus gborg?  (Kaare Rasmussen <kar@kakidata.dk>)
Re: Criteria for contrib/ versus gborg?  (greg@turnstep.com)
Re: Criteria for contrib/ versus gborg?  (Andrew Sullivan <andrew@libertyrms.info>)
List pgsql-hackers
Hi all,

As many of you know, PostgreSQL, Inc. has determined that Real Soon
Now is the time to release their older version of eRServer as a
contribution back to the rserv project.  That Has Not Happened Yet,
and I Do Not Speak For Them, and so on.  But I have agreed to do some
of the legwork for this, and I'm stuck doing the documentation, too. 
I thought that now would be a good time to ask whether it should
live as a separate project, or whether it should be in contrib.  I
don't actually get to make that decision, of course, but if everyone
agrees it should go to gborg, I can get to work on my own, whereas if
it has to go in contrib, I have to ask someone to do it for me, and I
have to find out whether it can go there now, after feature freeze. 
(If the answer to the latter is, "No," I guess I know what to do,
eh?)

Here are the arguments I can think of on each side:

pro contrib/:

- rserv is already there, and this is an upgrade
- allows us to say that PostgreSQL ships with field-tested replication in the source tree
- expands the visibility, increasing the possibility that some  replication system will one day be "built in"
- it's not that big, and since it's replacing code now there, it won't bloat the tarball

pro gborg:
- lots of other valuable things have been forced to go there (procedural languages come to mind; I happen to think that
wasa mistake, but of course, I don't run the circus)
 
- the new code depends on Java (with one voice now: "Bleccchhh!"), and since that doesn't ship with PostgreSQL, there's
noharm in asking people to download one more thing
 
- allows rserv to attain a separate release schedule, and there's plenty of work to do on this code, so it may see
changesfaster than the main PostgreSQL tree.
 

If you have any other arguments, or have an opinion on the matter,
I'd like to hear it.

Thanks,
A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M2P 2A8                                        +1 416 646 3304
x110



pgsql-hackers by date:

Previous
From: Kurt Roeckx
Date:
Subject: Re: OSF build fixed
Next
From: Tom Lane
Date:
Subject: Re: OSF build fixed