From: | David Steele <david(at)pgmasters(dot)net> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: 2018-03 CFM |
Date: | 2018-03-06 00:00:10 |
Message-ID: | 89de1de0-4d15-daaa-d2c7-30e06160a002@pgmasters.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 3/5/18 6:06 PM, Thomas Munro wrote:
> On Sat, Mar 3, 2018 at 1:18 AM, Aleksander Alekseev
>>
>> I don't think commitfest.cputube.org has the SQL data on whether patch
>> pass the tests. It just displays SVG images from travis-ci.org. Also
>> unfortunately both commitfest.postgresql.org and commitfest.cputube.org
>> currently don't have any kind of public API and don't allow to export
>> data, e.g. in CSV or JSON.
>
> My current plan is to propose that we post automated apply/build
> results into the Commitfest app itself so that it can show them, and
> then shut down commitfest.cputube.org.
+1
> The reason commitfest.cputube.org is so limited, not integrated yet
> and running on a strange domain name is because I decided to build an
> independent proof-of-concept first. I imagined that negotiating with
> many busy people on how such a thing should work and what would even
> be possible first would be more likely to stall, based on previous
> experiences with humans :-D
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.
Regards,
--
-David
david(at)pgmasters(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-03-06 00:11:52 | Re: [COMMITTERS] pgsql: Fix inadequate locking during get_rel_oids(). |
Previous Message | Tsunakawa, Takayuki | 2018-03-05 23:57:52 | RE: [bug fix] pg_rewind takes long time because it mistakenly copies data files |