If you do not already know how to read the pikefarm pages, they might seem a bit cryptic. Let us try to straighten out the question marks, starting with an overview of the system; what it does, what information it conveys and how it supports the pike developers in improving Pike. Pikefarm builds the most recent versions of Pike from CVS, on many different machines, hardware architectures and operating systems. When something changes in Pike, a new source distribution is made for the clients participating in the farm. They fetch it, compile it and, when successful, run the Pike testsuite on the result. Then they send back some log files with valuable feedback to the developers. Some post-processing later, a status blob appears in the matrix, indicating the level of success for the completed build. The rows of the table corresponds to different build machines, and the columns represents the results of different builds, the most recent one on the far right. For each build client (row), we see what operating system and hardware architeture it compiled for, and some also list a specific test profile used. In the screenshot above, we see that lukusion was set up to use the AIX native cc instead of what autoconf would have chosen. If you have a browser that supports CSS, you will see delimiters between dates and between different operating systems similar to those in the screenshot. The date/time stamps in the header of each column is the checkout time (in universal time) used for that build. In other words, if you want to, you can recreate a particular build by feeding that time to cvs with the -D option; for instance, to recreate build 103 above, we issue the command cvs update -D '2003-01-15 13:08:12 UTC' in our Pike tree and then run make as usual (assuming your system fulfills the prerequisites for building Pike from CVS; see README-CVS in your Pike tree for details). Okay, there already is a legend explaining the basics of the colorful blobs, but there is a bit more to say than what meets the eye here too. First, all colourful blobs are clickable and brings you to an in-depth view of the result reported by the client that compiled the build. That page is a topic of its own, though, so let's move on. A green blob means that the client built this Pike successfully, and ran the full test suite (about 170,000 tests in all at the time of writing this, and growing steadily) without a single fault. A yellow blob also means that the client built that Pike successfully, but that it failed on one or more tests in the testsuite; more details about what went wrong can be found in the verify log. Common causes are various kinds of resource starvation on the build machine; not enough memory, process table full, or even some operating system bug that was detected by the test suite (yes, the Pike test suite has a handful of tests designed to find such bugs to avoid debugging problems invented elsewhere). A red blob signifies that the client failed to build Pike for some reason (for obvious reasons, it did not run the test suite). Like in the case with the yellow blob, this does not necessarily indicate that the source package was at fault; it might be due to a client configuration error, of some sort. This time too, reading the returned log files, the make log in particular, is key to understanding what went wrong. Finally, the grey blobs signify all other conditions. Most commonly, the client never touched that build; perhaps because it was already busy with a previous build, perhaps because it was set up not to build more than once a day (or however often the owner of the machine prefers). Occasionally, when we have been busy working on Xenofarm (the build framework), some build results have even been lost or showed up late, also meaning gray blobs. Hence, when a client has managed to assemble a severely broken result package, it might escape the blob radar. To see what was checked in to Pike between two builds, you can click the changes link in the table footer. This will show you all checkins to Pike between that column's build and the build before it. Only checkins to the version corresponding to the table are listed, for improved relevance. Finally, there is a note of when the view was last updated, and the number of rows/clients that were in the list at the time. This number is sometimes lower than the number of build clients participating in pikefarm, if some clients have not reported any results for the past eleven builds (since they would just have been full of gray blobs anyway).