Re: Couple of minor buildfarm issues - Mailing list pgsql-hackers

Jim C. Nasby wrote:

>On Mon, Jul 25, 2005 at 08:49:45AM -0400, Andrew Dunstan wrote:
>  
>
>>We don't consider configuration settings ( e.g. 
>>--enable-integer-datetimes or --with-perl) to be part of the 
>>personality, and we don't currently track changes in them, nor in 
>>versions of third party libraries we might use ( e.g. openssl or libz). 
>>There is a limit to the lengths to which we can reasonably go, and I 
>>feel we are probably not too far from the sweet spot.
>>    
>>
>
>Well, the config options are always sent back in status reports... maybe
>if there was just a summary page that listed what those options were on
>a per-report basis; or even maybe diffing between reports to show
>changes.
>  
>

It's listed at the top of every log page. I am not sure where we should 
put it on other pages - the dashboard page is pretty full now - adding 2 
or 3 lines per machine to reflect the config options doesn't sound like 
a good idea. At one stage I thought of stealing some vertical space for 
8 or 10 columns of 10 pixels or so to show the state of the most 
importand build flag. I still might do that, if I can standardise the OS 
and Compiler info so that they get shorter (e.g. is just knowing that we 
have gcc n.m.o enough, or do we need the longer info produced by gcc -v? 
I'm inclined to reduce it to n.m.o.)

>Something else that I think would be good to send back with each status
>report is version info for everything relevant. gcc is obvious, I think
>the uname stuff reported covers all those bases. I think some linux
>distros have a file in /etc that specifies what distro it is, so
>including that might be good. Finally, it would be good to include
>version info for any external dependancies, especially since this could
>change depending on options specified to configure. I suspect that doing
>that will involve a change to configure, or maybe adding something to a
>makefile that just produces a sumary. Or perhaps the info is available
>in config.log. In any case, having a summary of config options and
>relevant version info should make it pretty easy to spot changes. Also,
>if the info is machine-readable it would be easy to do a summary report
>of what different options have how much coverage, etc.
>  
>

I have just about finished work on uploading complete logs, and 
config.log will contain version info on a lot of 3rd party stuff. For a 
sample, see the stage logs listed at   
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=oriole&dt=2005-07-25%2017:39:02

I do have one plea, which is that people with ideas review the requested 
features tracker on pgfoundry. I keep this up fairly well, even though 
some of the items are moderately old. See 
http://pgfoundry.org/tracker/?atid=241&group_id=1000040&func=browse

Many of the ideas that have been discussed are already on the list.

cheers

andrew