Closed Bug 757826 Opened 13 years ago Closed 13 years ago

[UI-RB-REPORT] Crashes per User by Build Date

Categories

(Socorro :: Webapp, task, P1)

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: espressive, Assigned: espressive)

References

Details

Attachments

(1 file)

Currently Crashes per ADU allows you to view the data by version, OS and type. This report needs to be extended to also allow a user to view Crashes per ADU by build date.
[:laura] The questions from bug 757822 apply here as well.
Blocks: 755293
Crashes by build date Crashes by build date: Product P Version V, including the channel (e.g. 15.0beta) Time Window W, expressed as weeks back in time from now, defaulting to 1 week Other criteria ZZ, which are not important for these changes X-axis: date of build Y-axis: crashes * 100 / ADU for crashes within 7 days of build date
Target Milestone: 13 → 14
Target Milestone: 14 → 15
Sheila, since Kairo is on vacation, can you give some feedback here? We're blocked.
Schalk, So a couple chronic issues to fix in this interface: Both "Type" and "OS" need an "All" option. Note that, at least for OS, "All" is NOT the same thing as Win & Mac & Lin, due to the presence of "unknown" OS crashes. The throttle selector needs to go away. Throttling is determined by the processors/database, not by the users. Not all product/versions have by-build data available -- only Aurora, Nightly, and Rapid Beta do. Do we want to prevent users from selecting inappropriate versions for "by build date"? If so, how? Otherwise it looks good, pending new mware services.
[:jberkus] 1) All is not an issue on the UI but needs changes on the PHP and Mware most likely. 2) throttle selector going away, is that in general or should this still available in some cases? If so, when? "Not all product/versions have by-build data available -- only Aurora, Nightly, and Rapid Beta do. Do we want to prevent users from selecting inappropriate versions for "by build date"? If so, how?" - this is also something I would need more detail on. If we want to implement validation, we need rules to validate against.
re: (2) I cannot think of any case in which the user would have a throttle selector available. We may want to *display* throttle values in some places, but it never makes sense to have the user set them. One of the product information services ... waiting for adrian to find out which ... will have a flag available, has_builds, which shows which products and versions have builds. It's really up to you and the mware how this should be handled. The UI issue, though, is how we handle it if the user selects, say, Firefox 16.0 Release, and then wants a "by build date" report. I don't have an answer for that.
[:jberkus] So we have to decide whether we want to keep the throttle selector, whether it be in a drop down or as a standard text field. It is there currently but, perhaps we can remove the selector and simply state what the throttle level is.
Schalk, I personally don't see any use in even displaying the throttle number, especially since it shows up in the data grid below. But that's really a question for the users.
Comment on attachment 635444 [details] UI change to allow for generating graphs and data by crash or build date I agree with Josh's comments, but they should go into followups as they are not addressed in the current UI as well. For the MoBeta step, this looks good. Let's file the followup, though.
Attachment #635444 - Flags: review?(kairo) → review+
Created the following follow on bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=770481 https://bugzilla.mozilla.org/show_bug.cgi?id=770482 https://bugzilla.mozilla.org/show_bug.cgi?id=770484 Just to confirm, these are targeted for after the mobeta launch not before or as part of, correct?
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Branch is at :: https://github.com/ossreleasefeed/socorro/tree/adu-by-build-date-757826 - Note, this is only the UI change and the functionality still needs to be developed.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: