Re: [HACKERS] buildfarm and rolling release distros

2014-07-04 Thread Christoph Berg
Re: Craig Ringer 2014-07-02 53b39638.9010...@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
-- 
c...@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


Re: [HACKERS] buildfarm and rolling release distros

2014-07-01 Thread Robert Haas
On Tue, Jul 1, 2014 at 12:49 PM, Andrew Dunstan and...@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


Re: [HACKERS] buildfarm and rolling release distros

2014-07-01 Thread Gavin Flower

On 02/07/14 06:02, Robert Haas wrote:

On Tue, Jul 1, 2014 at 12:49 PM, Andrew Dunstan and...@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


Re: [HACKERS] buildfarm and rolling release distros

2014-07-01 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes:
 On Tue, Jul 1, 2014 at 12:49 PM, Andrew Dunstan and...@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


Re: [HACKERS] buildfarm and rolling release distros

2014-07-01 Thread Noah Misch
On Tue, Jul 01, 2014 at 08:35:16PM -0400, Tom Lane wrote:
 Robert Haas robertmh...@gmail.com writes:
  On Tue, Jul 1, 2014 at 12:49 PM, Andrew Dunstan and...@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


Re: [HACKERS] buildfarm and rolling release distros

2014-07-01 Thread Craig Ringer
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 robertmh...@gmail.com writes:
 On Tue, Jul 1, 2014 at 12:49 PM, Andrew Dunstan and...@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