Re: commitfest html - wrong closing tag

On Sun, Jan 3, 2016 at 11:25 AM, Erik Rijkers <er(at)xs4all(dot)nl> wrote:

> On 2016-01-03 10:06, Magnus Hagander wrote:
>
>> On Sun, Jan 3, 2016 at 9:26 AM, Erik Rijkers <er(at)xs4all(dot)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.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/