Re: [PATCH] pg_sleep(interval) - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: [PATCH] pg_sleep(interval)
Date
Msg-id alpine.DEB.2.02.1310170944320.29366@sto
Whole thread Raw
In response to Re: [PATCH] pg_sleep(interval)  (Vik Fearing <vik.fearing@dalibo.com>)
Responses Re: [PATCH] pg_sleep(interval)  (Vik Fearing <vik.fearing@dalibo.com>)
List pgsql-hackers
Hello Vik,

> For: Josh, Stephen, me
> Against: Robert
> Neutral: Tom, you

For the record, I'm not neutral, I'm *FOR*. I reviewed it and said that I 
think it is fine. But I'm still nobody here:-)

My experience at trying to pass minor patches shows that the basic 
behavior is conservatism. Maybe this is necessary to the stability of the 
project, but this is really annoying for pretty small changes on side 
tools, and I think that it tends to over-conservatism and ampers good 
will. You have to argue a lot about trivial things. My ratio for passing 
very minor patches on pgbench for instance is 1:3 or worst, 1 unit 
programming and testing versus 3 units writing mails to argue about this 
and that. Maybe the ratio is better for big important patches. Your patch 
is quite representative, 1 line of trivial code, a few lines of tests and 
docs, and how many lines and time at writing mails?

> I don't know if that's enough of a consensus to commit it, but I do
> think it's not nearly enough of a consensus to reject it.

My guess is that it won't be committed if there is a single "but it might 
break one code or surprise one user somewhere in the universe", but I wish 
I'll be proven wrong. IMO, "returned with feedback" on a 1 liner is really 
akin to "rejected".

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: removing old ports and architectures
Next
From: Robert Haas
Date:
Subject: Re: [PATCH] pg_sleep(interval)