Re: Run pgindent now? - Mailing list pgsql-hackers
From | Andrew Dunstan |
---|---|
Subject | Re: Run pgindent now? |
Date | |
Msg-id | 555B35DD.2030201@dunslane.net Whole thread Raw |
In response to | Re: Run pgindent now? (Andrew Dunstan <andrew@dunslane.net>) |
Responses |
Re: Run pgindent now?
|
List | pgsql-hackers |
On 05/18/2015 08:06 PM, Andrew Dunstan wrote: > > On 05/18/2015 07:04 PM, Bruce Momjian wrote: >> On Mon, May 18, 2015 at 06:53:00PM -0400, Tom Lane wrote: >>> Robert Haas <robertmhaas@gmail.com> writes: >>>> On Mon, May 18, 2015 at 12:10 PM, Bruce Momjian <bruce@momjian.us> >>>> wrote: >>>>> There was talk last time of pgindent-ing head and all back branches, >>>>> because a patch applied to head and back branches was historically >>>>> only >>>>> pgindented in head, meaning that any future patches in that area >>>>> could >>>>> not be easily backpatched. >>>>> >>>>> Do we want to do this? >>>> I am personally not excited about that. I would rather leave the >>>> back-branches alone. >>> It would be awfully nice though if we didn't have to deal with random >>> cross-branch indenting differences. I've lost, maybe not years off my >>> life, but certainly weeks of not-very-pleasant make-work because of >>> that. >>> I'm surprised you've not had the same experience. >>> >>> If people were good about pgindenting patches meant to be back-patched >>> *before* they committed, it would not be such an issue, but they're not >>> very good about that. >> I couldn't figure out why we were getting that code drift, but now that >> Tom has identified why it happens, it seems good that we fix it. >>> Would it alleviate your concern any if we eased into this, like say >>> only >>> apply the back-branch pgindent run to 9.5 and later branches? Then at >>> least I could foresee the end of that particular annoyance. >>> >>> (BTW, one practical issue is where would we get typedef lists relevant >>> to the back branches. I'm not sure if the buildfarm infrastructure is >>> capable of collecting branch-specific data, or if we'd need to rather >>> than just using a union of all branches' typedefs.) >> Uh, I just happen to commit the typedef list file used for the pgindent >> run in src/tools/pgindent/typedefs.list, per branch, so we would just >> use the same file. If typedefs were added in a backbranch (unlikely), >> we probably wouldn't want to use them anyway. >> > > > > The buildfarm animals are perfectly capable of finding typedefs for > each branch. They haven't been because the default configuration is > only to collect them for HEAD. > > Changing this is easy, especially since I control five of the six > members currently reporting typedefs successfully, and Tom controls > the other one. > > I've currently set two of them to do run typedefs for all live branches. > > The other thing is that the server script that amalgamates them only > looks at HEAD. That will need to change. > > We would probably want an amalgamated list, because there could have > been symbols on old branches that were deleted in later branches. With > luck the presence of false positives wouldn't matter. It usually > doesn't seem to. > > OK, if you look at <http://www.pgbuildfarm.org/cgi-bin/typedefs.pl?show_list> you will be able to see the state of things. It's not even remotely pretty, and I am going to fix that, but it works. As you will be able to see, a number of buildfarm members are reporting on typedefs on all the live branches. You can get the list for each branch by hitting the appropriate link (essentially '/cgi-bin/typedefs.pl?branch=$branch'). If you ask for 'ALL' as the branch it gives you the amalgamated list over all branches. If you don't specify a branch at all, it gives you HEAD (which is buildfarm spelling for master), since that's what it did previously. I can change the default to ALL if that's what people want. Tom, if you want to get dromedary reporting on all branches, just remove the "branches => [ 'HEAD' ]," from the config. Enjoy. cheers andrew
pgsql-hackers by date: