Closed Bug 411397 Opened 14 years ago Closed 12 years ago
Add percentage to top crash reports
75.94 KB, image/jpeg
115.19 KB, image/jpeg
42.52 KB, image/jpeg
210.33 KB, image/png
26.13 KB, patch
|Details | Diff | Splinter Review|
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.)
Assignee: nobody → aking
Priority: -- → P2
Target Milestone: --- → 0.7
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.
lars, does this figure at all into https://wiki.mozilla.org/Breakpad/2009Q2RoadMap
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?
If it's not currently being used, feel free to delete. Would like this to be query-able in the future, though.
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.
It is not being used.
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 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.
Attachment #408412 - Attachment description: Trend Indi → Trend Indicators and Timespan Selector
Adding to the Trend Information would be a graph of # of crashes for a signature over time (or build number for development releases).
Another possible filter - Show only "Big Movers" which could include Big up, down, and NEW or Re-Entry Signatures to the top 100.
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.
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.
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.
This bug will track short term fixes for 1.0.1 release... Long term fixes are in Bug#525893
Summary: Need to add changes in rank to top crash reports → Add percentage to top crash reports
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.
Attachment #410698 - Flags: review?(ryan)
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.
Attachment #410698 - Flags: review?(ryan) → review+
(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.
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.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Component: Socorro → General
Product: Webtools → Socorro
You need to log in before you can comment on or make changes to this bug.