From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Need a builtin way to run all tests faster manner |
Date: | 2017-03-08 04:23:29 |
Message-ID: | 20170308042329.uvgw62gbxyoauizb@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017-03-07 20:58:35 +0800, Simon Riggs wrote:
> On 7 March 2017 at 20:36, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
>
> > FWIW, +1 on improving matters here.
>
> +1 also.
>
> I don't see what's wrong with relying on buildfarm though; testing is
> exactly what its there for.
>
> If we had a two-stage process, where committers can issue "trial
> commits" as a way of seeing if the build farm likes things. If they
> do, we can push to the main repo.
Personally that's not addressing my main concern, which is that the
latency of getting done with some patch/topic takes a long while. If I
have to wait for the buildfarm to check some preliminary patch, I still
have to afterwards work on pushing it to master. And very likely my
local check would finish a lot faster than a bunch of buildfarm animals
- I have after all a plenty powerfull machine, lots of cores, fast ssd,
lots of memory, ...
So I really want faster end-to-end test, not less cpu time spent on my
own machine.
- Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-03-08 04:29:10 | Re: CREATE/ALTER ROLE PASSWORD ('value' USING 'method') |
Previous Message | Ashutosh Bapat | 2017-03-08 04:18:11 | Re: foreign partition DDL regression tests |