Criteria for contrib/ versus gborg?

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 was a
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 no harm 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 changes faster
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(at)libertyrms(dot)info> M2P 2A8
+1 416 646 3304 x110