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

On Tue, Aug 11, 2009 at 11:56 AM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> OK, I get it.  Thanks for bearing with me.  The theory that the
>> smallest amount of patches remain outstanding at that point is
>> probably only true if the pgindent run is done relatively soon after
>> the last CommitFest.  In the 8.4 cycle, the pgindent run was done
>> something like 7 months after the start of the last CommitFest, by
>> which time a fair number of patches had accumulated.
>
> Yeah, that's a fair point.  Maybe we should institute a new policy that
> pgindent should happen immediately after close of the last commitfest
> in a cycle, instead of delaying until almost release time.
>
> A more aggressive approach would be to run pgindent immediately after
> the close of *each* commitfest, but that would tend to break patches
> that had gotten punted to the next fest.

I'm not sure whether that would work out to a net positive or not.
Presumably, it would mostly only break patches that had touched that
part of the code, and therefore were likely to be broken anyway. But
by the same token, since they're under active development, they're
also more likely to have already been fixed. I'm not sure there's a
good solution to this problem short of making pgindent easy enough
that we can make it a requirement for patch submission, and I'm not
sure that's practical.

But in any case, I think running pgindent immediately after the last
CommitFest rather than after a longish delay would be a good idea.

...Robert