Fabien,
> 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?
This is, personally, the *entire* reason I've been arguing for this
patch. I see the arguments against it as being a case of unnecessary
conservatism, and cynically realize that if a well-known major
contributor had proposed it, the patch would be committed already.
Our project has a serious, chronic problem with giving new
patch-submitters a bad experience, and this patch is a good example of
that. The ultimate result is that people go off to contribute to other
projects where submissions are easier and the rules for what gets
accepted are relatively transparent.
Personally, I don't care about pg_sleep(interval) really. But I do care
that a minor contributor be able to submit and have accepted a patch of
clear general usability, and not get it rejected on the basis of "it
might break something for someone even though we don't have a clear idea
who".
Now, I do think the argument of "we don't really need pg_sleep(interval)
because it's trivial to do yourself" has some merit, and that would be a
good reason to argue acceptance or not. However, to date that has not
been the topic of discussion.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
