Criteria for contrib/ versus gborg?

Поиск
Список
Период
Сортировка
От Andrew Sullivan
Тема Criteria for contrib/ versus gborg?
Дата
Msg-id 20030715201934.GF28141@libertyrms.info
обсуждение исходный текст
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Kurt Roeckx
Дата:
Сообщение: Re: OSF build fixed
Следующее
От: Tom Lane
Дата:
Сообщение: Re: OSF build fixed