Re: Patch submissions

Hi Dave,

I'm wondering what pain you are feeling around having multiple patches.

From my perspective it is much easier to deal with smaller commits as it
gives us a quicker way to understand each change if we want to look back at
history. I agree that each patch should work standalone (tests should be
passing, the application should run.) But, I think aiming for a patch size
that encompasses an entire feature is often too large.

When we were squashing patches and then having to go back and modify them,
we were spending a large portion of our time managing patches and branches
rather than working on code. With smaller patches, rebasing is much simpler
and easier to understand. So I'd really like to be able to continue to do
things this way. I do understand the desire not to have a 'bad' commit on
master.

Can you explain how having a large number of patches impacts your process
and maybe we can together come up with a process that works better for all
of us?
E.g. if you just wanted to review all the changes at once, you could do
`git apply *.patch` to review, and then `git am *.patch` when you are ready
to commit the changes.

Thanks,

Tira

On Wed, Mar 15, 2017 at 6:15 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:

> 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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-hackers
>