Re: Couple of minor buildfarm issues

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