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
On Thu, Aug 23, 2012 at 2:09 PM, John Lister <john(dot)lister(at)kickstone(dot)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
>> 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?
In response to
pgsql-jdbc by date
|Next:||From: dmp||Date: 2012-08-23 19:21:21|
|Subject: Pgsql_JDBC Support Proposal|
|Previous:||From: John Lister||Date: 2012-08-23 18:09:00|
|Subject: Re: setObject(...) with native Java arrays like String ?|