Re: buildfarm and "rolling release" distros - Mailing list pgsql-hackers

From Tom Lane
Subject Re: buildfarm and "rolling release" distros
Date
Msg-id 14703.1404261316@sss.pgh.pa.us
Whole thread Raw
In response to Re: buildfarm and "rolling release" distros  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: buildfarm and "rolling release" distros  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jul 1, 2014 at 12:49 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>> I've always been a bit reluctant to accept buildfarm members that are
>> constantly being updated, because it seemed to me that it created something
>> with too many variables. However, we occasionally get requests from people
>> who want to run on such platforms, and I'm also a bit reluctant to turn away
>> willing volunteers. We have one such application now in hand.
>> 
>> What do people think about this. Is it valuable to have? Do we have enough
>> stability from the buildfarm members that are not auto-updated that we can
>> accept a certain number of auto-updating members, where, if something
>> breaks, and it doesn't break elsewhere, then we suspect that something that
>> got upgraded broke the build?
>> 
>> I'm also not sure how to designate these machines. The buildfarm server
>> metadata isn't designed for auto-updating build platforms. But no doubt if
>> necessary we can come up with something.

> Off-hand, it seems like we could give it a try, and abandon the effort
> if it proves too problematic.

If a majority of buildfarm critters were like that, it'd be too confusing.
But as long as they are few, not all following the same update stream,
and well labeled in the buildfarm status page, I think we could cope.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Spinlocks and compiler/memory barriers
Next
From: Marti Raudsepp
Date:
Subject: Re: pg_xlogdump --stats