Skip site navigation (1) Skip section navigation (2)

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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, 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)
Date: 2009-08-11 16:43:09
Message-ID: 603c8f070908110943n4e88bbal932fdf420eaf57e7@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2009-08-11 16:52:37
Subject: Re: Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)
Previous:From: Tom LaneDate: 2009-08-11 16:11:49
Subject: Re: machine-readable explain output v4

pgsql-committers by date

Next:From: Andrew DunstanDate: 2009-08-11 16:52:37
Subject: Re: Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)
Previous:From: Tom LaneDate: 2009-08-11 15:56:18
Subject: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group