Обсуждение: buildfarm and "rolling release" distros
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. cheers andrew
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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 02/07/14 06:02, Robert Haas wrote: > 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. > How about prefixing the names of Auto Updating build farms with 'au_'? Cheers, Gavin
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
On Tue, Jul 01, 2014 at 08:35:16PM -0400, Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > On Tue, Jul 1, 2014 at 12:49 PM, Andrew Dunstan <andrew@dunslane.net> wrote: > >> 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. +1. The buildfarm has one such member already, anchovy, and I recall it having given at least one helpful forewarning. It shows as "Arch Linux testing [updated daily]", which is sufficient annotation for me. Its failure rate has been low; member-caused failures due to ENOSPC and other miscellany are a good deal more common. -- Noah Misch EnterpriseDB http://www.enterprisedb.com
On 07/02/2014 10:58 AM, Noah Misch wrote: > On Tue, Jul 01, 2014 at 08:35:16PM -0400, Tom Lane wrote: >> Robert Haas <robertmhaas@gmail.com> writes: >>> On Tue, Jul 1, 2014 at 12:49 PM, Andrew Dunstan <andrew@dunslane.net> wrote: >>>> 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. > > +1. The buildfarm has one such member already, anchovy, and I recall it > having given at least one helpful forewarning. It shows as "Arch Linux > testing [updated daily]", which is sufficient annotation for me. Its failure > rate has been low; member-caused failures due to ENOSPC and other miscellany > are a good deal more common. Yep - I see early notice of new gcc "special" behaviour, etc as quite valuable. If we're dubious about a result, we wait a few days and see if it goes away on its own. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
Re: Craig Ringer 2014-07-02 <53B39638.9010502@2ndquadrant.com> > > +1. The buildfarm has one such member already, anchovy, and I recall it > > having given at least one helpful forewarning. It shows as "Arch Linux > > testing [updated daily]", which is sufficient annotation for me. Its failure > > rate has been low; member-caused failures due to ENOSPC and other miscellany > > are a good deal more common. > > Yep - I see early notice of new gcc "special" behaviour, etc as quite > valuable. > > If we're dubious about a result, we wait a few days and see if it goes > away on its own. I was looking at the zoo some time ago and was surprised there's only a single animal running Debian unstable/testing - and that's on ia64 which Debian killed some months ago because no one seemed to care enough about maintaining the toolchain. Is this because unstable/testing are considered rolling releases? (On a second look, dugong seems to be running etch/4.0, which is... old.) My plan was to set up two animals, amd64 and i386, using the compiler flags we are using for the Debian packages, though I was still waiting for a VM in a soon-to-be-there cluster at credativ. That would have catched the ASLR problems we discussed some weeks ago quite early, I guess. Does it make sense to look into setting up that target? Christoph -- cb@df7cb.de | http://www.df7cb.de/