Front Page averages, revision summaries, histogram of fails/skips

[jjchen]

#17 : averages of skip/fail/error calculated in getStatistics, saved to revision summary table in updateCommit. Also changed the score function to be 10000*failscount.

#38 : finished failsDistr and skipsDistr. Finished frontend of failedFetches. Still need to figure out where to save the failed fetches info.

[jjchen]

@gwicke
I looked into at how failedFetches worked in the MySQL server, and it seems like an analogous way here would be to add a numfetcherrors filed to the tests table, and update it in addResult when we see a "DoesNotExist"? I wasn't sure about the efficiency of that though - does it seem like a good solution?

Also, I was looking into where to add the check for removing a test if the number of fetch errors reached the max. I was a little confused about how the testQueue is currently working. It seems like we init and fill it when the server starts up, then keep on dequeuing when we give out tests. Do we ever refill the test queue (like when we get a new commit)? Should we?

[gwicke]

@jjchen
A numFetchErrors field in the tests table sounds like a good solution to me. Although perhaps we can name it something more generic, maybe numDoesNotExistErrors ?

We should re-fill the test queue when we get a new commit. If we don't do so yet, then that's something we should add. It's probably not that hard.

[jjchen]

Okay, cool.

Yeah, that's what I thought - I didn't see where we were doing it, I'll check again and add it if we're not.

[gwicke]

It might be safer to explicitly list the fields you are expecting and in which order. If we refactor the schema it's better to get a query failure than getting unexpected data in specific offsets.