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

Re: branching for 9.2devel

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: branching for 9.2devel
Date: 2011-04-25 15:03:49
Message-ID: BANLkTin1ifhLn+aE2wWLKUWHN7ezJf6KCQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mon, Apr 25, 2011 at 3:45 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> One small issue that would have to be resolved before branching is
> whether and when to do a "final" pgindent run for 9.1.  Seems like the
> alternatives would be:
>

If the tools become easy to run is it possible we cold get to the
point where we do an indent run on every commit? This wold require a
stable list of system symbols plus the tool would need to add any new
symbols added by the patch. As long as the tool produced consistent
output I don't see that it would produce the spurious merge conflicts
we've been afraid of in the past. Those would only occur if a patch
went in without pgindent being run, someone developed a patch against
that tree, then pgindent was run before merging that patch. As long as
it's run on every patch on commit it shouldn't cause those problems
since nobody could use a non-pgindented code as their base.

Personally I've never really liked the pgindent run. White-space
always seemed like the least interesting of the code style issues,
none of which seemed terribly important compared to the more important
things like staying warning-clean and defensive coding rules. But if
we're going to do it letting things diverge for a whole release and
then running it once a year seems the worst of both worlds.

-- 
greg

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2011-04-25 15:16:13
Subject: Re: make check in contrib
Previous:From: Tom LaneDate: 2011-04-25 14:55:15
Subject: Re: intermittent FD regression check failure

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