From: | "Andrew Dunstan" <andrew(at)dunslane(dot)net> |
---|---|
To: | <josh(at)agliodbs(dot)com> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: inclusions WAS: Increased company involvement |
Date: | 2005-05-04 01:32:16 |
Message-ID: | 4569.24.211.165.134.1115170336.squirrel@www.dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Josh Berkus said:
> Dave, all:
>
>> This issue has come up before, and I opposed it then when the
>> interfaces were removed from the main tarball.
>> I really don't see the upside to reducing the size of the tarball at
>> the expense of ease of use. Â Seems to me we are
>> bending over backwards to make it easy for people with dial up
>> connections to download our "enterprise class"
>> database.
>
> Small tarball size isn't the *primary* reason for having our
> "push-it-out-to-pgFoundry" attitude, it's the *tertiary* reason. The
> main two reasons are:
>
> 1) If we start including everything that's "useful", where do we stop?
> There are enough pg add-ins to fill a CD -- 200 projects on GBorg and
> pgFoundry and others elsewhere. And some of them probably conflict
> with each other. Any decision to include some projects and not others
> will alienate people and possibly be a mis-evaluation; the
> libpq++/libpqxx mistake comes to mind.
>
> 2) As long as we're using CVS, the only way to organize autonomous
> project teams that have authority over their special areas but no
> ability to change central code is to "push out" projects to separate
> CVS trees.
>
>>From my perspective, putting together a coherent "distribution" of
>>PostgreSQL
> with all the add-ins you want is the job of commercial distributors and
> possibly OSS projects like Bizgres.
This water-torture campaign is disappointing.
How many projects on gborg have any active maintenance? Our community is
still small - we can ill afford fragmentation.
Tom and others have already pointed out the good technical reasons for not
divorcing PLs at least from the core code.
I was not around at the time of the libpq++/libpqxx issue. But, honestly,
fear of making a wrong decision should not be a reason not to make one.
As for CVS - if we can't do development the way we want using it then it's
time to replace it. I have been convinced for quite a while that it is
living on borrowed time, but I am far less certain about what should be used
to replace it. But making macro content decisions on the basis of what we
can do with CVS is just crazy.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2005-05-04 02:19:15 | Re: pg_locks needs a facelift |
Previous Message | Josh Berkus | 2005-05-04 01:06:28 | Re: inclusions WAS: Increased company involvement |