Peter Eisentraut wrote:
Tom Lane wrote:
Where the buildfarm falls down a bit is on the cross-product
coverage. But I think you're not going to get the cross product
without a call for port reports; there aren't that many people who
are going to offer dedicated time on every random platform there is.
Once RC1 is out and the build farm has picked it up, we should start filling out our little table with the build farm results and then look for ways to fill the holes. Does the build farm turn on all the compiler options? It really should. I'm looking for
/configure --prefix=SOMEWHERE --enable-thread-safety --with-tcl \ --with-perl --with-python --with-krb5 --with-pam -with-openssl
make
make install
make check
I know you're busy, but please take a few moments to check out how it works.
The configuration is chosen in the config file for each member, rather than being dictated centrally. Every report (success and failure) shows the config settings. The only setting that buildfarm needs to set itself is --prefix which is chosen relative to another config file setting. Everything else is up to the farm member sysadmin to choose appropriately.
A single member can run more than one branch, and per-branch config can be set up. A single machine can run more than one farm member (e.g. to use different compilers).
In addition to the steps above, we do the following:
initdb pg_ctl start make installcheck make contrib make contrib::installcheck pg_ctl stop
The worth of these extra steps has already been shown - a number of bugs of unknown age and provenance have been fixed, especially in contrib.
It is possible to run the buildfarm yourself without even being registered on www.pgbuildfarm.org - the script has a --nosend option which means it doesn't try to upload its results to the server. I encourage anyone interested in running buildfarm to try this option first.
cheers
andrew
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
