buildfarm and "rolling release" distros

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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/

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers