Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)
Date
Msg-id 603c8f070908111829i46edbe4k8830f8c0a9db6f06@mail.gmail.com
Whole thread Raw
In response to Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)  (Greg Stark <gsstark@mit.edu>)
Responses Re: Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)  (Andrew Dunstan <andrew@dunslane.net>)
Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)  (Bruce Momjian <bruce@momjian.us>)
Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Aug 11, 2009 at 8:10 PM, Greg Stark<gsstark@mit.edu> wrote:
> Of course
> in all likelihood tom would have rewritten their first patch
> anyways...

Maybe I'm taking life too seriously at the moment, but I find this
comment kind of snide and unhelpful.  I just went through the
experience of getting a series of four patches committed.  I believe
Tom changed the first two only a little.  Tom asked me to make
modifications that to the third one that were a lot of work but with
which I fundamentally agreed, and made some modifications of his own
to the fourth one which were improvements - minor, but improvements.

What is a bit frustrating to me is that a number of Tom's changes to
the first two patches were trivial whitespace changes that required me
to rebase for no obvious reason.   Either those changes were made
accidentally as Tom was fooling around with what I had done, or they
were made because Tom had some reason to believe that they would play
more nicely with pgindent, though what those reasons may have been is
entirely opaque to me.

I think that it is good for us as a community to talk about the
reasons why Tom changes patches.  If some of them are bad reasons,
maybe talking about it will persuade him to stop.  If they are good
reasons, perhaps the rest of us can learn from them.  But I think it
behooves us to talk about specific problems rather than engage in
open-ended griping.  I haven't been a member of this community for a
super-long time, but already I can see that there is a correlation
between who wrote the patch and how heavily it gets edited on commit.

Of course, it's not 100%.  Some of the thing that Tom wants are, at
least AFAICS, things that Tom wants merely because he wants them, and
not because they are better.  That's not wonderful, but any of us
would probably do the same thing, to some degree or other, if we were
in his shoes.  Magnus Hagander recently submitted a patch against my
pgcommitfest application, and just look what I did to him:

http://git.postgresql.org/gitweb?p=pgcommitfest.git;a=summary

...Robert


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Alpha 1 release notes
Next
From: Robert Haas
Date:
Subject: Re: dependencies for generated header files