Re: buildfarm issues

On Friday 04 March 2005 10:11, Andrew Dunstan wrote:
> Now that we've been running for a while there are a few buildfarm issues
> that I need to address.
>
> First, do we keep the right data about the members? Essentially, we
> keep: <operating_system, os_version, compiler, compiler_version,
> architecture>. For Linux, we genarlly ask for the
> Distribution/distro-version instead of the OS/os-version. However, that
> lead to interesting situations - Gentoo for example is so "flexible"
> that in version 2004.03 you might easily be using kernel version 2.4.x
> or 2.6.x ... in fact it's almost impossible to tell what might be
> installed on a Gentoo system, or how it was compiled. So I'm really not
> sure how we should treat such systems.
>
> Second is the fact that systems change over time. People upgrade their
> machines. I'm considering a facility to allow people to change the
> <os-version,compiler-version> aspects of their registered personality -
> these will become essentially timestamped pieces of information, so
> we'll still be able to tie a set of values to a history item.

What about using uname(1), cc -v, etc to glean this information and post it
with each event logged? I belive you have all this stuff already in the
config.log that is used already ?

>
> Third, what can be done to improve the usefulness of the server / web
> site? I already have the following items on my list of TODOs:
> . allow sorting of member list by personality feature (e.g. see all the
> OS/X boxes together)
> . filter dashboard page to only show certain members (this already works
> but you have to construct the list manually, e.g.
> http://www.pgbuildfarm.org/cgi-bin/show_status.pl?member=cat&member=dog&mem
>ber=loris&member=gibbon )
> . an email alerting system for when a system changes state
>
> Fourth, there are some significant gaps in the buildfarm coverage. I am
> currently personally supplying the Windows and Cygwin members, but since
> that is on my laptop which is frequently required for other work it's
> not ideal, and there can be large gaps. Other gaps include HPUX, for
> example. If you run a machine that should be covered and can help,
> please do. After the initial setup there should be very little work
> involved.

>
> Finally, a volunteer or two to help me with both running and
> administering this would be great. Knowledhge of perl and Template
> Toolkit a decided advantage.
>
> Buildfarm was created to assist the principal hackers - so any and all
> (constructive) input is welcome.
>
> cheers
>
> andrew
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org