Re: Bison 3.0 updates - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Bison 3.0 updates
Date
Msg-id 51F6B842.7060307@dunslane.net
Whole thread Raw
In response to Re: Bison 3.0 updates  (Marti Raudsepp <marti@juffo.org>)
Responses Re: Bison 3.0 updates
List pgsql-hackers
On 07/29/2013 02:26 PM, Marti Raudsepp wrote:
>> 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.
> What would be the right course of action if check_upgrade fails? Is it
> reasonable to expect buildfarm volunteers to downgrade the system and
> postpone until the problem is resolved?
>
> Or do you think the member should be removed from the farm until the
> build succeeds again? Sounds like worst of both worlds.
>


Neither, I don't think you're understanding me at all. The idea is to 
have some way of saying "well, the code is the same, but the tools have 
changed." i.e. we want to be able to hold one of these variables constant.

The buildfarm server knows how the run was invoked, and could 
distinguish runs done in this mode from other runs.

cheers

andrew



pgsql-hackers by date:

Previous
From: Marti Raudsepp
Date:
Subject: Re: Bison 3.0 updates
Next
From: Greg Stark
Date:
Subject: Re: Bison 3.0 updates