Re: Call for 7.5 feature completion

Tom Lane wrote:

>Peter Eisentraut <peter_e@gmx.net> writes:
>  
>
>>Marc G. Fournier wrote:
>>    
>>
>>>That is the plan ... unless someone knows a reason why they can't be
>>>built independently of the core?
>>>      
>>>
>
>  
>
>>How about this one:  Everything we have moved from the core to gborg so 
>>far has been a miserable failure.
>>    
>>
>
>JDBC seems to be doing fine ... but I think that exception just proves
>your point.  If there's not a viable community around a particular piece
>of code, pushing it out to gborg/pgFoundry won't magically create one.
>
>I strongly disagree with moving out the existing PLs; it's just a whole
>lot easier to maintain them alongside the backend.  (This is especially
>true of plpgsql of course, but it is very common that global edits hit
>the other PLs as well.)  I think Joe Conway's experience with
>maintaining plR separately shows the overhead involved.
>
>I would like to see plperlNG eventually supplant the existing plperl in
>core CVS.  If it weren't for the circular-build-dependency issue, I'd
>probably be in favor of pulling in plPHP too.
>  
>

Amen. plperlNG was always intended as a replacement.

In fact, one of the reasons I'm a bit sad about us rushing to feature 
freeze on 1 June is that Joshua and I had hoped to get a greatly beefed 
up plperl ready in time for 7.5, but I don't think we can make June 1.


>I do see a point to having pgFoundry though, which is that it allows
>more people to be granted direct commit access to the bits of code they
>are working on.  
>

Indeed. One of the great uses of pgfoundry is as a community site that 
can be used for things intended for eventual inclusion in the core but 
not yet ready for it.


>For the core project, I think we should continue the
>present policy of keeping commit access pretty closely held, so pulling
>all that stuff back in would make the committers a real bottleneck.
>With separate projects we can let each project determine its own commit
>access policies.
>  
>

It's a timing thing. When plperlng is ready we will present a largish 
patch or set of patches. At that time the separate project would shut 
down and plperl would once again be maintained as part of the core.


cheers

andrew