commitfest html - wrong closing tag

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?

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

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/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.

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