411397 - Add percentage to top crash reports

Status: RESOLVED FIXED

(Socorro :: General, task, P1)

Description

[Samuel Sidler (old account; do not CC)]

Reported by morgamic, Aug 03, 2007

Would be cool to do something like this:

Rank: 1
Last week: 5
Change: ^ 4

Something that shows delta since last week kind of like the bilboard top 100 :)

Comment 1 by bsmedberg, Aug 03, 2007

(No comment was entered for this change.)

--

Comment 2 by bsmedberg, Aug 09, 2007

This is a crappy solution: it uses the frequency (crashes with this signature/total
crashes) and provides an up-down indicator. The problem is that the UI is crappy.
Sayrer suggested sparklines (which is basically graphing by buildid,  issue 51 )... it
sounds like good UI, but has the same problem with database load.

I'm going to try an alternate approach by hand-aggregating the rankings first.

--

Comment 3 by bsmedberg, Aug 15, 2007

This adds a column of the form "↑ 5" to the report. When discussing UI with beltzner,
it is better to show the old rank rather than a change-in-rank number.

mike, can you review?

(Patch on Google code.)

Comment 1

[Michael Morgan [:morgamic]]

For test builds:

We need to make this a sparkline that compares the frequency of the current signature with how many crashes happened for that same build.  The sparkline would have an X axis of build IDS much like the graph on topcrashers for test releases.

For release builds:

Same but x-axis is time, not build ids.

Comment 2

[Wayne Mery (:wsmwk)]

lars, does this figure at all into https://wiki.mozilla.org/Breakpad/2009Q2RoadMap

Comment 3

[Frank Griswold [:griswolf] [:fgriswold]]

I am currently looking at topcrashes cron job, and thinking about reducing the number of columns in the database. Is it reasonable to lose the last_rank column, since that datum is readily available with a slight change to the query that extracts most recent data? Or should we continue to cache it?

Comment 4

[Michael Morgan [:morgamic]]

If it's not currently being used, feel free to delete.  Would like this to be query-able in the future, though.

Comment 5

[Frank Griswold [:griswolf] [:fgriswold]]

aking (or whoever maintains the online report page) must answer if it is now in use; and if there is significant downside to getting the data from a different query. My objection is theoretical (also known as 'gut feeling') that it is best not to cache single prior state because you may someday want multiple prior state, and one or more are readily available.

Comment 6

[Austin King [:ozten]]

It is not being used.

Comment 7

[Michael Morgan [:morgamic]]

Needs UI.

Comment 8

[chris hofmann]

I think this bug mostly talks about ranking a signature against all other signatures.  That will be, and has proven to be a bit helpful. 

But another approach is to show the trend increases and decreases against historical data for the signature.   

see the use case and discussion in [ Bug 519423 ] add tracking and alerts for "explosive" crash signatures

Comment 9

[Austin King [:ozten]]

Attachment: Trend Indicators and Timespan Selector

Comment 10

[Austin King [:ozten]]

Comment on attachment 408412 [details]
Trend Indicators and Timespan Selector

Here is a mockup that adds a column "Change" with trend Indicators for notable movers, New or Re-entry into the top 100 Signatures, and less notable trend info. It adds a Selector for switching the window of time for the trend report between windows of 3 days to 1 month.

Comment 11

[Austin King [:ozten]]

Attachment: Mockup Crash rates graph

Adding to the Trend Information would be a graph of # of crashes for a signature over time (or build number for development releases).

Comment 12

[Austin King [:ozten]]

Attachment: Mockup Show Only Big Movers Filter

Another possible filter - Show only "Big Movers" which could include Big up, down, and NEW or Re-Entry Signatures to the top 100.

Comment 13

[Austin King [:ozten]]

Attachment: Mockup of Rank indicated with bars

This mockup uses bars to show the relative change in rank of all rows in a more visual fashion. The column would be fixed width and percentages calculated on the overall highest and lowest movers.

Comment 14

[chris hofmann]

I like the graph in comment 11.

for the graphs that show pct. increase and changes in rankings I'm not sure how that is calculated and if it will show noise.  some experience with the these things in the report might tells us.

some signatures are sensitive to daily and weekly time windows so they might jump around a bit, but over the long run they aren't big movers.  these reports, depending on the time scale selected might show them as big movers.

lets give all these changes a whirl and see what is useful.

Comment 15

[Samuel Sidler (old account; do not CC)]

I'm not sure what the timespans should be (from the mockups), but definitely 7 and 14 days. Probably 2 or 3 days as well and maybe something on the high end. Worth trying something now and changing later as needed.

Comment 16

[Austin King [:ozten]]

This bug will track short term fixes for 1.0.1 release... Long term fixes are in Bug#525893

Comment 17

[Austin King [:ozten]]

Attachment: First stab at adding percentage

This patch adds relative percentage, start and end time span, and total crash count to give better context to top crashers report.

Also allows the report to be viewed in various configurable durations... 3, 7, 14, or 28 days.

Comment 18

[Ryan Snyder [:ryansnyder] [:rsnyder] [:rysny]]

Comment on attachment 410698 [details] [diff] [review]
First stab at adding percentage

Looking good.  Code is solid.  Made a few verbal recommendations to Austin regarding documentation and very minor code revisions.  Green light to commit.

Comment 19

[chris hofmann]

(In reply to comment #14)
> 
> some signatures are sensitive to daily and weekly time windows so they might
> jump around a bit, but over the long run they aren't big movers.  these
> reports, depending on the time scale selected might show them as big movers.

https://bugzilla.mozilla.org/show_bug.cgi?id=526992#c5 is an example of a big mover possible related to major or minor updates and people possibly down-grading

the trending info should try and tell us how many bugs like this we might have that have really screwing volume patterns, or volume patterns around things like updates, and malware proliferation and defense that effect firefox.

Comment 20

[Austin King [:ozten]]

The work scoped for 1.1 release is complete...

Rank and Trend will be in 1.2 release as noted in Bug#525893.

I'll look at various comments and mockups from both bugs.

Comment 21

[Austin King [:ozten]]

Forgot r1435.