Re: inclusions WAS: Increased company involvement - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: inclusions WAS: Increased company involvement
Date
Msg-id 4569.24.211.165.134.1115170336.squirrel@www.dunslane.net
Whole thread Raw
In response to Re: inclusions WAS: Increased company involvement  (Josh Berkus <josh@agliodbs.com>)
Responses Re: inclusions WAS: Increased company involvement  (Josh Berkus <josh@agliodbs.com>)
Re: inclusions WAS: Increased company involvement  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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




pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: pg_locks needs a facelift
Next
From: Tom Lane
Date:
Subject: Re: A proper fix for the conversion-function problem