Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor
NUM_cache_remove calls in error report path to a PG_TRY)
From:
Bruce Momjian <bruce(at)momjian(dot)us>
To:
Robert Haas <robertmhaas(at)gmail(dot)com>
Cc:
Greg Stark <gsstark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,
Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject:
Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor
NUM_cache_remove calls in error report path to a PG_TRY)
Robert Haas wrote:
> 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.
Sometimes I clean up code style in patches because I don't know there
are other patches depending on it; if I knew there were, I would be
less likely to change patched code, but it is hard to remember which
patches have others pending and which don't. Perhaps being explicit
might help remind patch appliers.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
