From: | Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: buildfarm and "rolling release" distros |
Date: | 2014-07-01 20:58:53 |
Message-ID: | 53B3210D.9020509@archidevsys.co.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 02/07/14 06:02, Robert Haas wrote:
> On Tue, Jul 1, 2014 at 12:49 PM, Andrew Dunstan <andrew(at)dunslane(dot)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.
>
How about prefixing the names of Auto Updating build farms with 'au_'?
Cheers,
Gavin
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2014-07-01 21:30:10 | Re: Can simplify 'limit 1' with slow function? |
Previous Message | Tom Lane | 2014-07-01 20:54:35 | Re: Spinlocks and compiler/memory barriers |