Re: Bison 3.0 updates

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Marti Raudsepp <marti(at)juffo(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PGBuildFarm <pgbuildfarm-members(at)pgfoundry(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bison 3.0 updates
Date: 2013-07-29 19:19:00
Message-ID: CAMkU=1wHd1AFUVyxijAtPObNnAM8ZBu=mso6c=aASwQr5Gg=RA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: buildfarm-members pgsql-hackers

On Mon, Jul 29, 2013 at 11:45 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
> 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.

Could it remove the need for manual intervention, by detecting if the
tools have changed first, and then suppressing the git pull and adding
the appropriate reporting flag, if they have?

Cheers,

Jeff

In response to

Browse buildfarm-members by date

  From Date Subject
Next Message Christian Ullrich 2013-07-29 22:54:36 Re: Bison 3.0 updates
Previous Message Greg Stark 2013-07-29 19:04:02 Re: Bison 3.0 updates

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2013-07-29 19:32:48 Re: Review: UNNEST (and other functions) WITH ORDINALITY
Previous Message Greg Stark 2013-07-29 19:04:02 Re: Bison 3.0 updates