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?
Re: Criteria for contrib/ versus gborg? Re: Criteria for contrib/ versus gborg? Re: Criteria for contrib/ versus gborg? |
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: