Re: 2018-03 CFM

From: Andres Freund <andres(at)anarazel(dot)de>
To: David Steele <david(at)pgmasters(dot)net>
Cc: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru>, Magnus Hagander <magnus(at)hagander(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 2018-03 CFM
Date: 2018-03-06 01:53:35
Message-ID: 20180306015335.pyqtvz2oigwecidx@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2018-03-05 20:49:02 -0500, David Steele wrote:
> On 3/5/18 8:33 PM, Thomas Munro wrote:
> > On Tue, Mar 6, 2018 at 1:00 PM, David Steele <david(at)pgmasters(dot)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!
>
> Another option would be too look at their graphs and figure out when
> their peak times are, then ramp up the builds outside that time.
>
> Even so, 2 builds at a time sounds pretty moderate to me.

Have we pinged them about what they're ok with? In previous interactions
I had with them they were pretty responsive.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2018-03-06 01:57:16 Re: All Taxi Services need Index Clustered Heap Append
Previous Message David Steele 2018-03-06 01:49:02 Re: 2018-03 CFM