Front page statistics

[gwicke]

Maintain the summary statistics currently used to display the front page

• In-memory: keep running averages, ratios of errors / fails / skips etc
• In storage: store summary per revision
• provide a backend interface for this
  • latest statistics (front page)
  • statistics for past revisions (long-term trends)
• hook up the front page to use these back-end interfaces

Who: John, Brando

[choucalate]

I have 3 questions:

1. Are the averages, ratios of errors/ fails/ skips all part of one revision?
2. For storing the summary per revision, do we need a new table for this? Or should I bring everything into memory and calculate it?
3. Where is the route for the statistics for past revisions/long-term trends? I don't think it's the green/yellow/red bar right?

[brando90]

I am unsure on the exact meaning of some of the statistics we are trying to compute. Is there a formula or a algorithm or something that describes them precisely?

Some of them are:
-Syntactic diffs
-Semantic diffs
-Errors

Also its a little unclear to me of what is everything that we want to compute.

[gwicke]

@choucalate: Averages are currently not persisted by revision, but it would be great if we could do so. The front page statistics display dynamically calculated stats based on the latest available information. We currently can't display only long-term trends in averages as dynamic computation of those would be way too expensive. So computing and persisting this would be great. For the latest revision / state it makes sense to keep this updated in memory & save it back to a cassandra table. For old revisions the stats can then be simply loaded from the db table.

@brando90: All stats are defined in the MySQL code, see server-mysql.js. Syntactic / semantic diffs are fails/skips in the JUnit result XML. Errors are errors in the JUnit XML or a test that returned no result within the retry count limit.

[choucalate]

I made a pull request #28

[choucalate]

I've more or less finished this issue, and I'll be issuing a pull request when I finish some topfails stuff
https://github.com/choucalate/testreduce - if you want to take a look at it

Still need to do before this issue is closed:
Possibly revision summaries (will probably restructure a couple things),
Crashers
Testing on scalability
Averages

[brando90]

@choucalate , are there still things to do here? Do you need any help in anything? I see you have the following list:

Possibly revision summaries (will probably restructure a couple things),
Crashers
Testing on scalability
Averages

Do you want to split them up or something? That way we don't end up doing the same thing twice or something?

[choucalate]

Sure! did you have an idea for how to split it?

[brando90]

Hey John! I think I don't have a good sense what the tasks actually entail, lol, so if I choose how to divide it, it might not be a fair division :p thus, if u feel u might know a better/more fair division of labour, go ahead an assign it. The one task I would not rather do is "Testing on scalability". Any of the other 3 I think sound found. What do you think?

[jjchen]

Hey guys! If there's still work to be done here, I can help too.

[choucalate]

Hooray, thank you guys for helping!

@brando90 could you implement the current one fail, one skip, other new fails features that exists on the new parsoid site? you'll have to make some new methods in cassandrabackend to fetch stuff (http://parsoid.wmflabs.org:8001/ ).
and
@jjchen could you do revision summaries and averages? I also don't have the front end completely set up to do averages yet either. You can probably just start with running averages and then do revision summaries later.

if you guys want to switch around roles or do something else that's fine as well