All, I'd like to clarify our patch submission expectations as I think there's been some confusion recently:
- Typically each new feature or change should be a single patch, ideally in it's own mail thread for future tracking/searching etc. - Large patches may be broken up into 2 or more smaller patches to aid the review process. Typically this might be infrastructure changes, then the new feature. A good rule of thumb is "is each patch useful in its own right?". - If patches are rejected (as is often the case for the first submission), please do not send back an ever-increasing set of patches correcting issues in the earlier ones. Please squash the changes down into a replacement patch. Patch review is a tedious and difficult job at the best of times - careful generation and organisation of patches makes a surprising difference to that process. Thanks all, and keep 'em coming :-) -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
