"BTW, the build farm is definitely proving its worth in terms of finding
unexpected problems quickly. That's another reason why I'm not too
concerned about going for a release with recent changes in the tree."
So we are definitely making a contribution.
Please remember to use a very high value on the force_every parameter in the config file. Originally I set the default for this to 24 hours, so some of you might be using that unintentionally. I recommend either turning it off altogether (use undef) or a value no lower than 168 (i.e. one week).
Your buildfarm machine does need to have a good notion of time - in most cases it should probably be setting time via NTP. There are two reasons for this: first, we work out if we need to do a build by comparing file ages, so if your clock is wrong this caculation can be skewed. Second, we report the snapshot time to the server, and this too should be accurate - I saw one member today that had apparently reported a snapshot some minutes in the future. That means it's clock must have been very badly wrong - probably at least 30 minutes wrong. Please make sure your buildfarm member is keeping accurate time.
If you see that your machine does not have green status on the dashboard page, please don't just let it sit. The aim is to get a perfect set of green readings if possible - at least on HEAD.
In a few days version 8.0 of postgres will be released. You should be prepared to add a new branch to your config files and crontabs as soon as CVS is branched - I assume the new branch will be REL8_0_STABLE.
I made a few changes to the web site today. The status summary page no longer shows data older than 30 days. By contrast, the member histories will now show up to 240 builds per branch, as opposed to 30 previously.
In the next month or two I intend to review how buildfarm works, both via this list and -hackers.