Re: Run pgindent now?

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: Run pgindent now?
Дата
Msg-id 555B35DD.2030201@dunslane.net
обсуждение исходный текст
Ответ на Re: Run pgindent now?  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: Run pgindent now?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Thom Brown
Дата:
Сообщение: Re: Per row status during INSERT .. ON CONFLICT UPDATE?
Следующее
От: Marko Tiikkaja
Дата:
Сообщение: Re: Per row status during INSERT .. ON CONFLICT UPDATE?