On 07/29/2013 11:05 AM, Tom Lane wrote:
Andrew Dunstan <and...@dunslane.net> writes:
On 07/29/2013 10:28 AM, Marti Raudsepp wrote:
Hmm? Anchovy is upgrading automatically to newest Arch Linux packages daily.
I assumed that's a good thing -- the purpose of build farm is to test
PostgreSQL in various different real-life environments? Arch Linux is
one such environment that adopts new packages very quickly. If Arch
users are unable to build PostgreSQL then surely it's good to be
notified by the build farm before real users start reporting problems?
The buildfarm is principally designed to detect when some change in the
Postgres code breaks something. As such, the expectation is that the
animals will provide a fairly stable platform. A totally moving target
will present us with false positives, since the failure could be due to
no action of ours at all.
I can see both sides of this. It's definitely nice to get early warning
when toolchain changes create new problems for Postgres, but it's not
clear that the buildfarm is the best way to get such notifications.
The big problem here is that it might take a long time before we have
a suitable fix, and in the meantime that buildfarm member is basically
useless: it can't tell us anything new, and even if it tried, probably
nobody would notice because they'd not realize the failure cause changed.
We've had cases before where a buildfarm member that was failing for
some known reason was unable to detect a later-introduced bug, so this
isn't hypothetical. (And I'm not too thrilled that we've let the
back-branch failures on anchovy persist for months, though I suppose
that's not as bad as a breakage in HEAD.)
Ideally we'd not rotate toolchain updates into the buildfarm until
they'd been checked out in some other way. On the other hand, this
doesn't seem like a big enough problem to justify building some
different infrastructure for it, so I'm not seeing a practical way
to do better.
There has to be something between "set in stone and never changes" and
"auto-updates everything every 24 hours" that would suit us.
I'm toying with the idea of a check_upgrade mode for the buildfarm
client where it wouldn't do a git pull, but would report changes if the
build result was different from the previous result. You'd run this
immediately after pulling new changes into your OS. Other, brighter
ideas welcome.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
