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



---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to