Re: B-Tree support function number 3 (strxfrm() optimization)

On Fri, Apr 4, 2014 at 4:29 PM, Greg Stark <stark(at)mit(dot)edu> wrote:
> On Fri, Apr 4, 2014 at 12:15 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> >> Perhaps I shouldn't lay my own guilt trip on other committers --- but
>> >> I think it would be a bad precedent to not deal with the existing patch
>> >> queue first.
>> >
>> > +1
>>
>> +1
>
> I don't think we have to promise a strict priority queue and preempt all
> other development. But I agree loosely that processing patches that have
> been around should be a higher priority.
>
> I've been meaning to do more review for a while and just took a skim through
> the queue. There are only a couple I feel I can contribute with so I'm going
> to work on those and then if it's still before the feature freeze I would
> like to go ahead with Peter's patch. I think it's generally a good patch.

To be honest, I think that's just flat-out inappropriate. There were
over 100 patches in this CommitFest and there's not a single committed
patch that has your name on it even as a reviewer, let alone a
committer. When a committer says, hey, I'm going to commit XYZ, that
basically forces anybody who might have an objection to it to drop
what they're doing and object fast, before it's too late. In other
words, the people who just said that they are too busy reviewing
patches that were timely submitted and don't want to divert effort
from that to handle patches that weren't are going to have to do that
anyway, or lose their right to object. I think that's unfair. You're
essentially leveraging a commit bit that you haven't used in more than
three years to try to push a patch that was submitted months too late
to the head of the review queue - and, just to put icing on the cake,
it just so happens that you and the patch author work for the same
employer. I have no objection to people committing patches written by
others who work at the same company, but only if those patches have
gone through a full, fair, and public review, with ample opportunity
for other people to complain if they don't like it. That is obviously
not the case here.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company