Re: 2018-03 CFM - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: 2018-03 CFM
Date
Msg-id CAEepm=1qZsFXr0QceHmH0OP-Zds-u8SVJbxNDZPS3Eacv=2zvg@mail.gmail.com
Whole thread Raw
In response to Re: 2018-03 CFM  (David Steele <david@pgmasters.net>)
Responses Re: 2018-03 CFM  (David Steele <david@pgmasters.net>)
List pgsql-hackers
On Tue, Mar 6, 2018 at 1:00 PM, David Steele <david@pgmasters.net> wrote:
> I've been using commitfest.cputube.org for reference since the last CF,
> though I'm unsure if it rechecks patches when master changes, so I do
> that manually.  Anyway, that's probably too much to ask since every push
> to master would set off a 100+ builds on Travis.
>
> Maybe just reapply once a day when master changes?  And only rebuild if
> the patch changes?  Not perfect, but it would work in most cases.
>
> I use Travis for the pgBackRest project, and I try to be considerate of
> the free resources.  I dislike the idea of throwing a ton of builds at
> them without considering what would be most useful.

It's triggered by new patches AND new commits.  Since I want to be
polite, I try to avoid having more than 2 builds going at a time.
They generously invite open source projects like us to run up to 5
builds concurrently for free, so I thought I was being at least a
little bit considerate, though I guess I could drop it down to 1.  It
goes in rotating order of Commitfest ID and waits in between to limit
the rate. The constant stream of both commits and patches during a
200+ entry Commitfest mean that it's effectively building around the
clock and each CF entry gets retested about twice a day.  Perhaps I
could make it smarter... I'll think about that.  Thanks!

-- 
Thomas Munro
http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs
Next
From: Michael Paquier
Date:
Subject: Re: Change RangeVarGetRelidExtended() to take flags argument?