Re: Alpha release process - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Alpha release process
Date
Msg-id 603c8f070907131453q6d6997ftebda8514eddafb12@mail.gmail.com
Whole thread Raw
In response to Re: Alpha release process  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Alpha release process  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: Alpha release process  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Jul 13, 2009 at 3:57 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>> Peter Eisentraut <peter_e@gmx.net> wrote:
>>> It will mostly look like a beta release
>
>> No pgindent run I assume?
>
> No, that would tend to break pending patches.
>
> There's been some talk of pgindenting just new code added by patches
> at the time they're committed.  We don't seem to have the infrastructure
> for a selective pgindent run, though, so I'm not sure quite how that'd
> work.  Anything more global should only happen at release times, when
> (hopefully) there is the smallest volume of open patches to adjust.

The problem is that if you do a pgindent run with every commit, you'll
break any the case where someone has developed a series of patches
where each depends on the preceding one in the series.  On the other
hand, the longer you wait to run pgindent, the more people have a
chance to start doing work that will eventually have to be rebased
over the whitespace change.

What would be really nice is to provide an easy and PORTABLE way for
patch submitters to run pgindent themselves.  Then you can pgindent on
every commit, and if you break somebody's patch series, it's there own
fault for not pgindenting it correctly before they submitted it.

I have no idea how to make that work, however.  It seems like a hard problem.

...Robert


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Mostly Harmless: c++bookends - patch 2 of 4
Next
From: Peter Eisentraut
Date:
Subject: Re: Mostly Harmless: c++configure - patch 3 of 4