Thread: Couple of minor buildfarm issues
One pretty silly point: I notice that http://www.pgbuildfarm.org/index.html says "The build farm software does not currently run on Windows". This is out of date no? One not so trivial question: do we have a policy about system/compiler updates on buildfarm members? Arguably, if I'm running say OS X 10.2 and I update to 10.4, it's no longer the same machine and we should retire the buildfarm ID (the "animal") and issue a new one to denote that the results aren't necessarily comparable. (I choose the OS X update as an example with malice aforethought, since in fact our older branches do not work on 10.4.) Ditto for, say, a major gcc update. At the very least it seems we need some longitudinal tracking of OS and compiler and other software versions (eg Python version is relevant to plpython). As best I can see from here, the identification of a buildfarm member's software versions is static, and that isn't very realistic unless we enforce it to be so. regards, tom lane
Tom Lane wrote: >One pretty silly point: I notice that >http://www.pgbuildfarm.org/index.html >says "The build farm software does not currently run on Windows". >This is out of date no? > > Fixed, thanks. >One not so trivial question: do we have a policy about system/compiler >updates on buildfarm members? Arguably, if I'm running say OS X 10.2 >and I update to 10.4, it's no longer the same machine and we should >retire the buildfarm ID (the "animal") and issue a new one to denote >that the results aren't necessarily comparable. (I choose the OS X >update as an example with malice aforethought, since in fact our older >branches do not work on 10.4.) Ditto for, say, a major gcc update. > >At the very least it seems we need some longitudinal tracking of OS and >compiler and other software versions (eg Python version is relevant to >plpython). As best I can see from here, the identification of a >buildfarm member's software versions is static, and that isn't very >realistic unless we enforce it to be so. > > > These thoughts do not come upon me as a bolt from the blue. ;-) The personality of a machine is defined by the tuple of: <OS, OSVersion, Compiler, CompilerVersion, Architecture> except that for Linux we say that the OS is the Distribution, not the kernel (or glibc) version, because when we started somebody (I forget who) said that the kernel versionwas probably the least interesting datum. OTOH, in some cases the word "distribution" has been stretched more than somewhat - Gentoo is really more a "build your own distro" system than a distribution in itself. Now, we have several problems with the setup. First, the fields to describe all these are text fields both on the registration form and in the database, and there are no edit restrictions or check/FK constraints. So we have something of a mess, which I need to get around to cleaning up. Secondly, as you observe, machines change. I have resisted suggestions to allow arbitrary dynamic updates of personality, precisely so that we can track history in a sensible fashion. My current plan is to provide generational personalities only for cases of OSVersion or CompilerVersion update. Build results will be tied to a particular generation, and this will be reflected on the history page. Any other change would require retirement/reregistration. Right now, we don't have that, and any change in these items should result in member retirement/reregistration. 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. Enforcing these details is probably going to be hard. This is mainly a trust system. On another note, I am close to having provision for the complete log upload you requested - my test box has it working and loading into the db - next I will work on providing web access to it. cheers andrew
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. 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. -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
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
On Mon, Jul 25, 2005 at 07:06:33PM -0400, Andrew Dunstan wrote: > >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.) Oh, I wasn't suggesting on the main status page, just in some way that it's easy to see a) coverage amongst different machines (so this would show the latest info for each machine) and b) what changes have been made on a specific machine in the past. I think those two would cover most cases. -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
Andrew Dunstan wrote:
> 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.)
I have reduced some of the clutter from OS names/versions and compiler
names/versions, and can reduce some more in the status column, that
means we will be able to have a bunch of flags indicating what build
criteria were used. I am mainly inclined to flag these:
--enable-cassert --enable-debug
--enable-nls --enable-integer-datetimes --with-perl
--with-python --with-tcl --with-krb5
--with-openssl
If we have to drop any for reasons of space it would probably be the
first two. Given the fact there are 9 of these I could make it a simple
set of digits [1-9] and provide a legend, although that might not be
quite so visually pleasing.
Any other bids?
cheers
andrew
Given the current issue with the SCO Optimizer and --enable-debug, I'd like to keep it on the list. I'd also like to see a way to run both --enable-debug and not --enable-debug runs either alternately or With a command line arg. Same with the --enable-integer-datetimes switch. Just my $0.02. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 US
On Jul 27, 2005, at 11:27 AM, Andrew Dunstan wrote: > I have reduced some of the clutter from OS names/versions and > compiler names/versions, Out of curiosity, how did you do this? Did you update the original registration data or make some kind of mapping? > and can reduce some more in the status column, that means we will > be able to have a bunch of flags indicating what build criteria > were used. I am mainly inclined to flag these: > > --enable-cassert > --enable-debug > --enable-nls > --enable-integer-datetimes > --with-perl > --with-python > --with-tcl > --with-krb5 > --with-openssl > > > If we have to drop any for reasons of space it would probably be > the first two. Given the fact there are 9 of these I could make it > a simple set of digits [1-9] and provide a legend, although that > might not be quite so visually pleasing. I'll see if I can't come up with a simple table that can provide without resorting to numbers. I'm thinking of using abbreviations such as: --enable-cassert => assert, --enable-debug => debug, --enable-nls => nls, --enable-integer-datetimes => int-date, --with-perl => perl, --with-python => python, --with-tcl => tcl, --with-krb5 => krb5, --with-openssl => ssl, Michael Glaesemann grzm myrealbox com
On Jul 27, 2005, at 11:42 AM, Larry Rosenman wrote: > Given the current issue with the SCO Optimizer and --enable-debug, > I'd like > to keep it on the list. > > I'd also like to see a way to run both --enable-debug and not -- > enable-debug > runs either alternately or > With a command line arg. > > Same with the --enable-integer-datetimes switch. > > Just my $0.02. ++ (does that make $0.03? $1.03? $1?) Michael Glaesemann grzm myrealbox com
Larry Rosenman wrote: >I'd also like to see a way to run both --enable-debug and not --enable-debug >runs either alternately or >With a command line arg. > >Same with the --enable-integer-datetimes switch. > > > In general we don't want you changing the settings much. That goes to the issue of longitudinal tracking that Tom was talking about the other day. It can be done, e.g. with an alternate config file. But it's not recommended. I am working on some extra debugging assistance - essentially a "run from source" facility. Jim Nasby has played with it and sent me some fixes, which I have not had time to try out. cheers andrew
Michael Glaesemann wrote: > > On Jul 27, 2005, at 11:27 AM, Andrew Dunstan wrote: > >> I have reduced some of the clutter from OS names/versions and >> compiler names/versions, > > > Out of curiosity, how did you do this? Did you update the original > registration data or make some kind of mapping? Fixed the original. e.g. 'Linux Debian' and 'Debian Linux' bacame just 'Debian', removed build dates from compiler versions. And so on. > > > I'll see if I can't come up with a simple table that can provide > without resorting to numbers. I'm thinking of using abbreviations > such as: > > --enable-cassert => assert, > --enable-debug => debug, > --enable-nls => nls, > --enable-integer-datetimes => int-date, > --with-perl => perl, > --with-python => python, > --with-tcl => tcl, > --with-krb5 => krb5, > --with-openssl => ssl, > No, it need to be really short. We have maybe 200 pixels to display all 9 flags. So, digits or ticks marks or some such. Anyway, let's take this offline. cheers andrew