Re: buildfarm and "rolling release" distros

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: buildfarm and "rolling release" distros
Date: 2014-07-02 00:35:16
Message-ID: 14703.1404261316@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marti Raudsepp 2014-07-02 01:20:31 Re: pg_xlogdump --stats
Previous Message Tom Lane 2014-07-02 00:21:37 Re: Spinlocks and compiler/memory barriers