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

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgreSQL(dot)org
Subject: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)
Date: 2009-08-11 15:56:18
Message-ID: 10143.1250006178@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Aug 10, 2009 at 6:52 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Only if they aren't applied by then.  One reason that we normally only
>> run pgindent at the end of the devel cycle is that that's when
>> (presumably) the smallest amount of patches remain outstanding.

> 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.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Joshua D. DrakeDate: 2009-08-11 15:58:00
Subject: Re: "Hot standby"?
Previous:From: Fujii MasaoDate: 2009-08-11 15:30:01
Subject: Re: Hot standby and synchronous replication status

pgsql-committers by date

Next:From: Robert HaasDate: 2009-08-11 16:43:09
Subject: Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)
Previous:From: Bruce MomjianDate: 2009-08-11 12:02:58
Subject: pgsql: Remove tab in SGML.

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