Re: [pgsql-advocacy] Increased company involvement - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: [pgsql-advocacy] Increased company involvement
Date
Msg-id 42768D1F.2090208@dunslane.net
Whole thread Raw
In response to Re: [pgsql-advocacy] Increased company involvement  ("Marc G. Fournier" <scrappy@postgresql.org>)
List pgsql-hackers

Marc G. Fournier wrote:

>>
>> The issue is that we have had to wack around the existing PL languages
>> for almost every release to make them work with server changes, and
>> being outside our CVS, plPHP isn't getting that whacking.
>
>
> And the point is, as Tom has pointed out with tsearch2, that even *in* 
> CVS, it is a fair amount of work to 'whack' other ppls code ... it 
> shouldn't be Tom's responsibility (which is generally what it comes 
> down to) to keep someone else's code up to speed with changes in the 
> server ...
>
>

Just to reiterate a previous point I have made: buildfarm does build 
(and mostly test) things in the core. I have *no* plans at all to make 
it test things not in core - currently we get code from one source and 
it would be a huge effort to change that. I *do* have plans to make it 
run the tests for each PL in core, if they are configured in the build. 
So be careful about pushing or keeping out of core things that are now 
or will soon get buildfarm testing.

The argument about tarball size I can't take seriously - the plperl 
directory for example takes 148k uncompressed in a distribution of 72 Mb.

I agree that contrib needs some considerable cleanup. For example, is 
there any good reason not to fold in the crypto stuff?

cheers

andrew




pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: [pgsql-advocacy] Increased company involvement
Next
From: Bruce Momjian
Date:
Subject: Re: [pgsql-advocacy] Decision Process WAS: Increased company