Re: Bison 3.0 updates - Mailing list pgsql-hackers

On 07/29/2013 11:05 AM, Tom Lane wrote:
> Andrew Dunstan <andrew@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