Re: commitfest html - wrong closing tag - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: commitfest html - wrong closing tag
Date
Msg-id CABUevEwnA9EHPwwAt3tF3GmpfihYGyNpcChxodqNH3Jpkfb_NA@mail.gmail.com
Whole thread Raw
In response to Re: commitfest html - wrong closing tag  (Erik Rijkers <er@xs4all.nl>)
List pgsql-hackers


On Sun, Jan 3, 2016 at 11:25 AM, Erik Rijkers <er@xs4all.nl> wrote:
On 2016-01-03 10:06, Magnus Hagander wrote:
On Sun, Jan 3, 2016 at 9:26 AM, Erik Rijkers <er@xs4all.nl> wrote:
an erroneous '</p>'. It should be '</td>'.

Is there a particular thing you're trying to parse the data out for? As in
is there some data that we should already be providing in a structured
format instead of requiring parsing it out?


I'm just trying to set up a way to compile and test all outstanding patches.

It might perhaps be handy to have that patches table's columns somewhere (in tab-separated, perhaps?).

Of course most of the work is downstream of that download, anyway. Compile & check (also rather simple) but especially to have some loading/testing (both general, and specific to the patch's goal).


Well, if you get everything else turned into something that works well and is generally useful, then we can definitely look at putting up an API endpoint that you can call to get the data in a structured format rather than parsing it out of the HTML (which might randomly break if we make changes..)

Actually having the ability to do that was one of the things we talked about early on (an API and just having a job somewhere that could auto-post the status), but nobody actually got around to doing it.... One of the most basic ideas then would be to just add a state to a patch which could be set to "fails to apply" or "fails to compile" for example, by a job, and an API to basically pick patches off a queue (which would serve up new versions etc automatically). If you're interested in turning it into something like that, feel free to ping me off-list for a discussion of the (very small) amount of things discussed back then.

--

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [PATCH] Refactoring of LWLock tranches
Next
From: "andres@anarazel.de"
Date:
Subject: Re: [PATCH] Refactoring of LWLock tranches