Обсуждение: commitfest html - wrong closing tag
Hi, I noticed (trying to parse out the "Latest patch" urls) that in the html of the commitfest pages, for instance in: https://commitfest.postgresql.org/8/ all rows of the html-table (I think it is the "Committer"-column) contain an erroneous '</p>'. It should be '</td>'. See example below, the '<td></p>' should obviously be '<td></td>'. Browsers don't seem to mind (and I can easily "parse around" it) but maybe it can be fixed? Thanks, Erik Rijkers (html from https://commitfest.postgresql.org/8/ ) ------8<------------------ <tr> <td><a href="298/">Improve handling of OOM errors in libpq making process hangling for COPY and bind (take 2)</a></td> <td><span class="label label-info">Ready for Committer</span></td> <td>Michael Paquier (michael-kun)</td> <td>Amit Kapila (amitkapila), Heikki Linnakangas (heikki)</td> <td></p> <td style="white-space: nowrap;">2015-12-20<br/>13:14</td> <td style="white-space: nowrap;">2015-12-15<br/>06:54</td> </tr> ------8<------------------
On Sun, Jan 3, 2016 at 9:26 AM, Erik Rijkers <er@xs4all.nl> wrote:
Hi,
I noticed (trying to parse out the "Latest patch" urls) that
in the html of the commitfest pages, for instance in:
https://commitfest.postgresql.org/8/
all rows of the html-table (I think it is the "Committer"-column) contain an erroneous '</p>'. It should be '</td>'.
See example below, the '<td></p>' should obviously be '<td></td>'.
Browsers don't seem to mind (and I can easily "parse around" it) but maybe it can be fixed?
That is indeed obviously wrong. Fixed and deployed. (http://git.postgresql.org/gitweb/?p=pgcommitfest2.git;a=commitdiff;h=3d583f3fb0184b4858395a385438e4cb22080612)
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?
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). thanks, Erik Rijkers
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.