Well my personal guidelines would be as follows
1) Has to come with a test case
2) If it requires docs it needs those as well
3) Don't change the format of the code
4) Performance is important ( not sure exactly what that means )
Lastly how to determine if it is a good idea to accept it? I'd like to
see more discussion from the group, voting would be one way.
However as I said some very large companies use this as I said. Just
because it satisfies your itch doesn't make it a good idea for
everyone else.
Dave Cramer
dave.cramer(at)credativ(dot)ca
http://www.credativ.ca
On Thu, Aug 23, 2012 at 2:09 PM, John Lister <john.lister@kickstone.com> wrote:
> On 23/08/2012 16:00, Dave Cramer wrote:
>>
>> To be candid, I need help managing the patches.
>>
>> Many times the patches come in without test cases or without
>> documentation. All of these things require me to spend time I don't
>> have.
>>
>> Also many patches or requests are very specific "itches" which solve a
>> particular problem for the submitter. Every new feature adds
>> complexity and possibly negatively effects performance. It is useful
>> to keep in mind that the driver is used by lots of other people who
>> will not benefit from this particular feature request.
>>
>>
>> So I am open to suggestions as to how to manage this better. I know
>> that the main postgresql project has a system where other people
>> review patches. This seems like it is a good idea.
>>
>> Notionally someone other than the submitter would review the patch.
>>
> Sounds like a good idea, I'm happy to review patches if required. Is there a
> set of guidelines that need to be followed
> in determining if a patch should be accepted?
>
> John