Re: [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
Date
Msg-id 470D2208.8040803@dunslane.net
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
List pgsql-hackers

Tom Lane wrote:
> Robert Treat <xzilla@users.sourceforge.net> writes:
>   
>> On Wednesday 10 October 2007 10:57, Andrew Dunstan wrote:
>>     
>>> One of pgfoundry's explicit purposes is for backports of features. 
>>>       
>
>   
>> I can't think of any contrib modules we've added that also required
>> backwards comptible modules to be released on foundry at the same
>> time.  ISTM that such a requirement would be an argument that such a
>> thing doesn't belong in contrib at all.
>>     
>
> AFAICT there isn't any market for a backport of txid.  Slony won't
> depend on it before their next release, which will require PG >= 8.3
> for other reasons.  Skytools already has an internal version in their
> existing releases.  And the code won't work before PG 8.2 so any
> backport couldn't go very far anyway.
>
> So while Andrew's statement is true in general, I don't think
> it's very relevant to a consideration of what to do with txid.
>
>             
>   

The context of this quote was referring to pg_standby, not txid.

We wouldn't be having this discussion at all if we had not had a 
horribly long period beween feature freeze and beta. We'd be way past 
the stage where anyone would consider adding something to contrib or 
anywhere else. The only cure I can see for that is that we need much 
more stringent criteria for what is a candidate to make the cut. I know 
I committed things that really weren't ready when I got hold of them, 
and required a lot of work to get them anything like ready. Arguably 
that didn't matter because they weren't on the critical path, but I 
think all projects need to be handled equitably. I'm sure Tom faced the 
same problem I did ten times over.

cheers

andrew


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Skytools committed without hackers discussion/review
Next
From: Michael Glaesemann
Date:
Subject: Re: Skytools committed without hackers discussion/review