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

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Euler Taveira de Oliveira <euler(at)timbira(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, pgsql-hackers(at)postgresql(dot)org, Jan Wieck <JanWieck(at)yahoo(dot)com>, Marko Kreen <markokr(at)gmail(dot)com>
Subject: Re: [COMMITTERS] pgsql: Added the Skytools extended transaction ID module to contrib as
Date: 2007-10-10 19:03:36
Message-ID: 470D2208.8040803@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Tom Lane wrote:
> Robert Treat <xzilla(at)users(dot)sourceforge(dot)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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Michael Glaesemann 2007-10-10 19:13:16 Re: Skytools committed without hackers discussion/review
Previous Message Joshua D. Drake 2007-10-10 18:57:56 Re: Skytools committed without hackers discussion/review

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Glaesemann 2007-10-10 19:13:16 Re: Skytools committed without hackers discussion/review
Previous Message Joshua D. Drake 2007-10-10 18:57:56 Re: Skytools committed without hackers discussion/review