Closed Bug 640238 Opened 13 years ago Closed 12 years ago

Get chofmann's nightly crash trends reports into Socorro

Categories

(Socorro :: General, task, P1)

Product:
Socorro
Component:
General
Type:
task

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: kairo, Assigned: brandon)

References

Details

(Whiteboard: [Q42011wanted] [Q12012wanted])

Attachments

(2 files, 7 obsolete files)

New graph proposal
46.02 KB, image/png
Details
graph inside socorro with dummy data
112.59 KB, image/png
Details 
We should work on integrating a number of current "third-party" reports into Socorro proper, with the benefit of better optimized data gathering (using our databases) and nicer UI.

One of those is the nightly crash trends report chofmann has in http://people.mozilla.org/~chofmann/crash-stats/ (mozilla-central-crash-trend.csv in the dated subdirs).

chofmann will fill in further details on that.
Depends on: 629029
Target Milestone: --- → 1.7.8
Assignee: nobody → chris.lonnen
Trying to figure out how to present this information. Can you give me some insight into what you're looking to get out of it when you examine this report? 

Specifically:
* Are the individual numbers vital or are you looking at the trend?
* Are the raw crashes or the percentage more important? Is one significantly more important than the other?
* Do you tend to look at the row or the column? 

Also, there isn't a whole lot of structure in that folder and it would be helpful if you could point out exactly what scripts are involved in generating this report.
as mentioned in the people directory this stuff as moved to
https://crash-analysis.mozilla.com/chofmann/?C=M;O=D

some of the stuff about showing the  number of releases where any particular crash is found like in this report https://crash-analysis.mozilla.com/chofmann/20110502/top-6.0a1.html  has already been integrated as part of recent socorro update.

work remaining is to produce reports like this:

https://crash-analysis.mozilla.com/chofmann/20110502/compare-rank-4.0.1-6.0a1-4.0-3.6.16.txt

we will need admin panel entries for setting up the releases that we want to compare.  maybe something like

TRUNK=6.0a1
AURORA=5.0a2
BETA=4.0.1
MAJOR=4.0
MAINT1=3.6.16
MAINTBETA=3.6.17

then process needs to create rank list of crashes for each of the named releases, then lists the ranking order for a given release and then shows the rankings in the other releases for comparison.

the top rank report that we already have like https://crash-stats.mozilla.com/topcrasher/byversion/Firefox/5.0a2 would be a good place in integrate this into but that report is getting a bit large and unwieldy.  one design approach would be to make the set of columns that get shown configurable like we do with bugzilla.

this helps to identify new and volume regressions, and can also be used in the other direction to show when fixes are making impact.


another report to be integrated is this one

https://crash-analysis.mozilla.com/chofmann/20110502/mozilla-central-crash-trend.csv

here we show both the number, and pct., of crashes for each of the recent daily mozilla-central/nightly builds.  this report helps to identify when nightly builds become unstable due to introduction of crashes, or increases in usage.

the best place to link in that information  is 

https://crash-stats.mozilla.com/products/Firefox/builds and the reports linked from that page.

I think the top plugin crash report like
https://crash-analysis.mozilla.com/chofmann/20110502/top-plugin-crashes-5.0a2.html

is covered under another bug.
(In reply to comment #2)
> work remaining is to produce reports like this:

We have different bug reports for each of those.

> another report to be integrated is this one
> 
> https://crash-analysis.mozilla.com/chofmann/20110502/mozilla-central-crash-trend.csv
> 
> here we show both the number, and pct., of crashes for each of the recent daily
> mozilla-central/nightly builds.  this report helps to identify when nightly
> builds become unstable due to introduction of crashes, or increases in usage.
> 
> the best place to link in that information  is 
> 
> https://crash-stats.mozilla.com/products/Firefox/builds and the reports linked
> from that page.


This is the one covered here.
(In reply to comment #1)
> Trying to figure out how to present this information. Can you give me some
> insight into what you're looking to get out of it when you examine this
> report? 

I'm currently not really looking into that one much myself, will need to re-check with those that do, but here are my thoughts on it:

> Specifically:
> * Are the individual numbers vital or are you looking at the trend?

Mostly at the trend, I'd think.

> * Are the raw crashes or the percentage more important? Is one significantly
> more important than the other?

I for myself would even be more interested in some kind of crashes/ADU than in either raw crashes or percentage - but on those numbers, I'd say those that make trends more obvious are more important.

> * Do you tend to look at the row or the column? 

Hmm, that's one thing I'm not sure I can answer, let me check with people using the report.

> Also, there isn't a whole lot of structure in that folder and it would be
> helpful if you could point out exactly what scripts are involved in
> generating this report.

Did the statement from Chris help? If not, I guess he'll need to point out the details, as it's actually his work.
>> * Are the raw crashes or the percentage more important? Is one significantly
>> more important than the other?
>
>I for myself would even be more interested in some kind of crashes/ADU than in
>either raw crashes or percentage - but on those numbers, I'd say those that
>make trends more obvious are more important.

yeah, if we could get to crashes per 100 adu, per build, that would provide the best number.  I'm not sure there is an easy way to get that data out of metrics or into socorro at this point.
After what we talked about yesterday and checking these posts, it sounds like what you want is already in the Crashes per Active Daily User (1) charts. I could modify that page to add the cumulative graph we talked about if that would help.


[1] - https://crash-stats.mozilla.com/daily?form_selection=by_version&p=Firefox&v[]=5.0&throttle[]=100.00&v[]=&throttle[]=10.00&v[]=&throttle[]=100.00&v[]=&throttle[]=10.00&hang_type=any&os[]=Windows&os[]=Mac&os[]=Linux&date_start=2011-04-28&date_end=2011-05-12&submit=Generate
the crash per 100 user chart shows something different than https://crash-analysis.mozilla.com/chofmann/mozilla-central-crash-trend.csv

the current crash per 100 chart shows all builds for a given version, and that's good enough for the case were one build (say for a final release) dominates the crash reporting for a released version.

mozilla-central-crash-trend.csv does a more precise breakdown so we can see how crashy any given daily/weekly build is, the how the volatility of crashes is changing day-to-day for builds that are 1, 2, 3, and more days old.

I also changed this around a bit today so we can do comparative day-by-day analysis on mozilla-central, aurora, and beta channels.

https://crash-analysis.mozilla.com/chofmann/mozilla-central-crash-trend.csv
https://crash-analysis.mozilla.com/chofmann/mozilla-aurora-crash-trend.csv
https://crash-analysis.mozilla.com/chofmann/mozilla-beta-crash-trend.csv
Target Milestone: 1.7.8 → 2.0
Target Milestone: 2.0 → 2.1
Target Milestone: 2.1 → 2.2
Target Milestone: 2.2 → 2.3
We could add a new matview for crashes/build fairly easily.

One question, though: should it include non-Mozilla builds?  We get a lot of buildids we don't recognize.
> should it include non-Mozilla builds?

these are not interesting to us.
Target Milestone: 2.3 → 2.4
Whiteboard: Q42011wanted
Assignee: chris.lonnen → sneethling
Status: NEW → ASSIGNED
My thinking is to model this very much on for example the crashes per ADU etc. reports so, I am thinking you will have the option to either select a day or a date range (most likely a week), then a version and finally you can choose between raw numbers or percentages.

So if for example you select 2011-04-24, version 5.0a2 and raw numbers, the graph would plot:

Crash_frm      alldays  1day    2days   3days   4days   5days   6days   7days   8days   9days   10days
20110424 5.0a2  459     110     249     302     364     402     407     414     424     435     445

If you select a week range then one could possibly plot the following:

X-Axis labels    X-Axis Values
--------------------------------

2011-04-24       :: 459 (= all days)
2011-04-25       :: 656 (= all days)
2011-04-26       :: 756 (= all days)
2011-04-27       :: 757 (= all days)
2011-04-28       :: 666 (= all days)
2011-04-29       :: 603 (= all days)
2011-04-30       :: 557 (= all days)

So the first gives you the crash trend for a biuld from a specific day and the second gives you the trend for different build of the same version over the course of a week. I might be completely off here so, comments and suggestions are most welcome.
Schalk, KaiRo, Chris,

How dependable are the ADU numbers for nightly builds?  Are they going to give you something useful, or do we just want to go with raw crash numbers per Schalk's suggestion above?
(In reply to Josh Berkus from comment #11)
> How dependable are the ADU numbers for nightly builds?  Are they going to
> give you something useful, or do we just want to go with raw crash numbers
> per Schalk's suggestion above?

We are creating the front page graphs using those ADU numbers and there they are fine, so what makes you question how dependable they are? The only problem we have is sometimes all ADU numbers (not just nighty) are coming in late from metrics, but that's something we should fix on their side.
Going with raw crash numbers for the moment might be fine - using crashes/ADU would be nicer, though. So maybe something for a followup, if that eases things.
Kairo,

I was checking some individual nightly builds and coming up with nothing for ADU.  However, that appears to be an issue with how metrics is inserting the data ... I'll take it up with them.
Depends on: 700466
If you are looking at adu numbers within a day or two of the build creation date there might not be much data there;

I could see where depending on:
 timing of the build, 
 low number of users on the particular build channel, 
 timing of the user update ping, 
 and timing of the metrics report running 
could create the condition where we might not see adu's for some builds for a couple of days.
Chris, Josh, Robert,

Should I start the UI work using the raw numbers, for now, as I explained above? https://bugzilla.mozilla.org/show_bug.cgi?id=640238#c10
Chris,

Yeah, that's why I think it makes sense to provide a "raw number" option as well as a "crashes/ADU" option.   In the cases where ADU levels are too low to work for reports, developers will still be able to get useful information.

Schalk,

Please provide me with a list of columns you need and I'll write a matview.
(In reply to Schalk Neethling from comment #15)
> Should I start the UI work using the raw numbers, for now, as I explained
> above?

I think it makes sense as that leads at least to progressing on this.

I think we'll need ADUs per build ID for this (which we need in other places as well in the future) and I'm not sure if we have that already. I don't really see the comment #14 concerns, esp. varying ADU numbers dependent on how many days a build was out there is an argument _for_ doing crashes/ADU there as crash volume is also low when not many people have yet updated to a build.

Still, if you start with raw crash numbers for now, we have something to work with, and we can improve on that by going crashes/ADU in a followup.
Attached image Graph for weekly trend (obsolete) — 

    
    

    
  

      
      
      
      

        Attached image
          
        Graph for build on a specific day (obsolete)
        — 
      

    


  

    
    

    
  
Uploaded to attachments showing the graphs I had in mind. It can still be tweeked etc. Feedback very welcome.

    
    

    
  
I'm traveling so its a bit hard to stay up on bug mail, and this one is a bit confusing to understand a this point.  

Are the latest attachments trying to model raw data that we have in https://crash-analysis.mozilla.com/chofmann/20110502/mozilla-central-crash-trend.csv ?

what we are trying to show there is the concentration of crashes around individual builds or groups of builds based on age, and compare them to other builds in the past of similar age (or time in the field).

I'm trying to look for compression of crashes in latest builds and see if there are lots of them within the last few days, and how that compares to other builds just after they were released when they probably had the same number of users.  I'm looking down each column to do this.  Its a rough way to calibrate the uptake on of builds, so that's why getting ADU numbers would help to help us with more direct comparisons.

here is an example using a slice of the data from
https://crash-analysis.mozilla.com/chofmann/mozilla-central-crash-trend.csv

date of bld

        release 
               tl crashes all days
                       less than
                       1 day    2 days  3days old

20110905 9.0a1	2157 	518	1101	1215	
20110906 9.0a1	1977 	555	1099	1265	
20110907 9.0a1	2053 	493	1234	1370	
20110908 9.0a1	1654 	416	945	1076	
20110909 9.0a1	3021 	1715	2330	2435	
20110910 9.0a1	3742 	1132	3174	3267	
20110911 9.0a1	3248 	1121	2310	2764	
20110912 9.0a1	3092 	1101	2202	2419	
20110913 9.0a1	2634 	473	1776	2030	
20110914 9.0a1	1817 	507	988	1287	
20110915 9.0a1	1869 	610	1166	1270	

from this I can see that builds really got unstable after sept 9. and it was the latest 1 day old build that was causing all the problems.

from that I'd look at new signatures that showed up on that day, or signatures that might we might have seen an increase in volume.

on sept 13 the one day old build reverted back to historical crash volumes, and total crashes on the nightly channel started to inch downward at that point.

I'm not sure that your prototypes tell me that kind of story or analyze the data in that way.

    
    

    
  


  
Chris, is this more what you were after?

    
    

    
  
yeah, that will work ok.  I kind of liked my stacked  bar chart better but this is fine.

    
    

    
  
Chris, how many days do you want to plot on the graph? 10 days? Also, do you want to add the All days data to this graph as well?

    
    

    
  
Lonnen, Schalk,

Please let me know what columns/data you need to produce this graph.

    
    

    
  
(In reply to Schalk Neethling from comment #24)
> Chris, how many days do you want to plot on the graph? 10 days? Also, do you
> want to add the All days data to this graph as well?

30-60 or even 90 days of data would be good to have to track trends.

"builds over 10 days old" could be tracked as one lump sum.

    
    

    
  
(In reply to chris hofmann from comment #23)
> yeah, that will work ok.  I kind of liked my stacked  bar chart better but
> this is fine.

Would there be benefit to you and [:kairo] if we have another graph that shows the data for 'all days' on a specific date over a date range? So, it will plot something like:

{label: "2011-04-24", data: 459},
{label: "2011-04-25", data: 656},
{label: "2011-04-26", data: 756},
{label: "2011-04-27", data: 757},
{label: "2011-04-28", data: 666},
{label: "2011-04-29", data: 603},
{label: "2011-04-30", data: 557}

So data uses the 'alldays' column for each date.

    
    

    
  

      
      
      
      

        Attached image
          
        The alldays based graph (obsolete)
        — 
      

    


  
Chris, so this is the other one I was referring to. Maybe having both would be the ideal?

    
    

    
  
I think that additional one might be helpful, but I'll leave the decision to Chris.

    
    

    
  
Chris, your thoughts on the additional graph?

    
    

    
  
It is really best to have the "all builds" graph on the same graph as the  latest 1, 2, 3,... days graph.   the purpose of this is to understand the overall crashiness of builds on a particular channel, and then to quickly drill down to see if the crashes are primarly coming from the set of recent builds, or older builds.

    
    

    
  
(In reply to chris hofmann from comment #31)
> It is really best to have the "all builds" graph on the same graph as the 
> latest 1, 2, 3,... days graph.   the purpose of this is to understand the
> overall crashiness of builds on a particular channel, and then to quickly
> drill down to see if the crashes are primarly coming from the set of recent
> builds, or older builds.

Chris, so basically I will add another line to the chart that will plot the crash numbers from the all days column? Just want to make 100% sure I am correct. Thanks

    
    

    
  
yes.

    
  
Whiteboard: Q42011wanted → [Q42011wanted] [Q12012wanted]
Component: Socorro → General
Product: Webtools → Socorro

    
    

    
  
[:chofmann] The UI for the graphs has a from and to date. Is there a specific date range this will be limited to? i.e. date range cannot be for more then 7 days or, is this unlimited?

    
    

    
  
It would be nice for this to have a longer history than 7 days.  Its handy for this to cover 6, 12, or 18 weeks to see where previous rapid releases were in their crashiness durning previous development cycles.

    
    

    
  
[:chofmann] One thing to note in this regard is our limited screen real estate. As each of the date ticks at the bottom of the chart represents a specific date and is lined up with it's vertical line, we are going to start getting an overlap when the date range is really long.

Also, do you want the date displayed as year/month/day or only month/day?

    
    

    
  
that's why we should put the date on the vertical axis.  that would allow adequate number of stacked builds and distribution of crashes within those builds on horizontal access, and however number of days that we wanted to show on the vertical axis.

just a graphical  representation of comment 21 would be best.

    
    

    
  
[:chofmann] let me experiment with this

    
    

    
  
[:chofmann] this will then change it to a bar chart as apposed to a line chart?

    
    

    
  
yes.

    
    

    
  

      
      
      
      

        Attached image
          
        New graph proposal (obsolete)
        — 
      

    


  
[:chofmann] [:kairo] Please see the revised graph and let me know whether this is preferable to the one previously signed of on.

        Attachment #573495 -
        Attachment is obsolete: true

        Attachment #573496 -
        Attachment is obsolete: true

        Attachment #574581 -
        Attachment is obsolete: true

        Attachment #576160 -
        Attachment is obsolete: true

    
    

    
  
if we can, I think we should stack the bars.

    
    

    
  
[:chofmann] I did the stacking with flot but I do not think the end result is very intuative but, it might just be me. I will send you a sample so you can have a look.
Target Milestone: 2.4 → 2.4.1

    
    

    
  

      
      
      
      

        Attached image
          
        New graph proposal with dates back on xaxis (obsolete)
        — 
      

    


  
please let me know what you think of this idea. If we only show the day/month at the bottom we should be able to fit quite a bit of data into the graph and the hover points will make it easier to see exactly what each point reflects whilst the legend provides general guidance

    
    

    
  
I don't think those values logically stack, or am I understanding something wrong here?

    
    

    
  
[:chofmann] [:kairo] if the numbers on the left proof to be confusing, which I can see them being, I can hide them without loosing the date when hovering over a point.

[:kairo] Do you feel the initial graph works better or do you feel there might be a way to make this stacking order work?

    
    

    
  
I still don't understand the data well enough to make a really well-founded statement on how stacking could work or not, sorry.

    
    

    
  


  
this is what I think the chart should look like.

    
    

    
  
[:chofmann] So, I am assuming that the numbers below are cumulative of all of the bars in total. So there is no way to know how much each color, i.e. all days/ 1 day/ 2 days etc. presents? 

I have something like this mocked up but, thought it would not work well for you, hence I did not send it. Let me post this and we can work from there. 

Thanks for all the feedback [:chofmann] and [:kairo]

    
    

    
  
so each segment of the bar should represent the number of crashes for builds that are 1, 2, and 3 days old, and last segment is accumulation of builds 4 through N.  the full length of the bar is the total crashes for that version on a single day.

if we made it so a mouse hover brought up the numerical value that would be great too.

a quick scan of the chart just helps us to see which are the crashies days, and which builds have the highest contribution to that crashiness.

    
    

    
  
[:chofmann] So, the data is as follows:

First color: total crashes for 1 day old builds
Second color: total crashes for 2 day old builds
Third color: total crashes for 3 day old builds
Fourth color: total crashes for builds 4 days and older

Full bar: total crashes for build on All Days

This means that All Days is a calculated value and does not have it's own entry(color) on the bar.

I will provide the mockup for this in a short while.

    
    

    
  

      
      
      
      

        Attached image
          
        New graph proposal
        — 
      

    


  
Please let me know your thoughts on this concept

        Attachment #585737 -
        Attachment is obsolete: true

        Attachment #586042 -
        Attachment is obsolete: true

        Attachment #586109 -
        Attachment is obsolete: true

    
    

    
  
looks good.  I'd extend this out to 7 days, but what you have is fine.

thanks!

    
    

    
  
[:chofmann] Just to clarify, what do you mean by extend this to 7 days? Just want to make sure I am not missing something.

    
    

    
  
make the bar segments include 7 days worth of builds instead of 3.

    
    

    
  
[:chofmann] I believe I might have misunderstood a previous comment then re: "1, 2, and 3 days old, and last segment is accumulation of builds 4 through N."

When you say extend the segments to 7 days instead of three, do you mean the above comment should change to be:

1, 2, 3, up to 7 days old, and last segment is accumulation of builds 8 through N?

    
    

    
  
yes.

    
    

    
  


  
[:chofmann] Here is the graph inside Socorro with some dummy data and 7 days and 8+ day segments.

    
    

    
  
perfect!

    
    

    
  
[:chofmann] Last question, do we want to enforce a date range of at least 7 days for the from and to date? So we will never show less then a week's worth of data.

    
    

    
  
no, we want to see less than 7 days if we haven't hit that threashold yet.  those early days are the hardest to understand and compare after we start up development of a new release and this is the tool that helps that the most.

    
    

    
  
one last one then, when the graph page initially shows, what range of data should be loaded? Maybe data for the last 7 days?

    
    

    
  
(In reply to Schalk Neethling from comment #62)
> one last one then, when the graph page initially shows, what range of data
> should be loaded? Maybe data for the last 7 days?


https://bugzilla.mozilla.org/show_bug.cgi?id=640238#c35

It would be nice for this to have a longer history than 7 days.  Its handy for this to cover 6, 12, or 18 weeks to see where previous rapid releases were in their crashiness durning previous development cycles.

    
    

    
  
[:chofmann] No, the date range is completely open to the user to choose. What I am referring to is on initial load of the page, can we simply load data from the past week instead of showing no data until the user selects a date range?

    
    

    
  
FYI: Chofmann has chosen Rank Compare as his top priority for 2.4.1.   As such, the DB underpinnings of this report may not get done until 2.4.2.

    
    

    
  
(In reply to Schalk Neethling from comment #64)
> [:chofmann] No, the date range is completely open to the user to choose.
> What I am referring to is on initial load of the page, can we simply load
> data from the past week instead of showing no data until the user selects a
> date range?

Given that we're displaying data aging on nightlies for all nightlies, relative to the day of build, I don't understand how the user would be "choosing" any date whatsoever.  Explain?

    
    

    
  
The final branch with all of the UI code has been pushed to the following branch:
https://github.com/ossreleasefeed/socorro/tree/crash-trends-report

NOTE:

Currently the Mockjax code used for testing is still part of this, you can safely remove the mock inside crash_trends.js, just update the URL for the Ajax call ;), as well as the mockjax plugin.
Assignee: sneethling → bsavage
Target Milestone: 2.4.1 → 2.4.3

    
  
Target Milestone: 2.4.3 → 2.4.4

    
  
Priority: -- → P1
Target Milestone: 2.4.4 → 2.4.3

    
    

    
  
OK, this is going to be a very large matview.

Given that, I think we need to set a data lifetime on the data, that is, a maximum number of days you can go back in time from the present day.

Would everyone be OK with 6 weeks?

    
    

    
  
Also, an additional question:

If the buildID on a crash report doesn't match any known nightly/aurora buildID, is everyone OK with simply ignorning those crashes?  If not, then what else should we do with them?

    
    

    
  
(In reply to [:jberkus] Josh Berkus from comment #68)
> Would everyone be OK with 6 weeks?

I would. I'd even be happy with restricting to, say, 2 weeks per build (i.e. build date + 14 days) for nightly/aurora/beta (and not sure if we need this report for release at all, maybe not).

(In reply to [:jberkus] Josh Berkus from comment #69)
> If the buildID on a crash report doesn't match any known nightly/aurora
> buildID, is everyone OK with simply ignorning those crashes?

I'm happy with only using known nightly/aurora/beta builds.

    
    

    
  
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #70)
> (and not sure if we need this
> report for release at all, maybe not).

Actually, not even sure we want this for beta, as we have the usual reports for every beta anyhow. But the further split in this report might make sense possibly.

    
    

    
  
Kairo,

Ok, 2 weeks after release of each nightly/aurora it is.

    
    

    
  
Should the graph show absolute counts of crashes, or crashes/ADU?

    
    

    
  
this bug is getting hard to read, but I think we are after counts here.

    
    

    
  
Yes, as I stated before in this bug, let's do only counts right now. We can do crashes/ADU in a followup.

    
    

    
  
I think this will require more work than we can accomplish before tomorrow's branch, so pushing this out to relieve the pressure.
Target Milestone: 2.4.3 → 2.4.4

    
  
Assignee: bsavage → nobody

    
  
Target Milestone: 2.4.4 → 2.5.1

    
  
Target Milestone: 2.5.1 → 2.5.2

    
  
Assignee: nobody → bsavage
Target Milestone: 2.5.2 → 2.5.3

    
  
Target Milestone: 3 → 4

    
    

    
  
Josh and I worked out the SQL we'll need:

SELECT product_name, version_string, product_version_id, build_date, days_out sum(report_count) as report_count FROM nightly_builds JOIN product_versions USING ( product_version_id ) WHERE report_date <= %date AND report_date > ( %date - %days ) AND product_name = %product AND version_string = %version GROUP BY product_name, version_string, product_version_id, build_date, days_out;

    
  
Target Milestone: 4 → 5

    
    

    
  
Some builds are 0 days old, indicating the crash belonged to the build issued that particular day. Should these be separate from 1 day old builds, or should the 1 day old mean "one day or younger"?

    
    

    
  
Reassigned back to Schalk to resolve front-end issues and tidy up.
Assignee: bsavage → sneethling
Assignee: sneethling → bsavage

    
    

    
  
The backend integration is done. I need a couple things from Espressive to ensure that we have this ready to ship:

* Integration with the UI in some meaningful way so it can be found
* The form that allows for date, product and version selection should populate with the parameters in the query string. These are all passed to the view layer.
* The form needs to add the option to select a product, and a version based on what product was selected.

    
    

    
  
[:brandon] I was just thinking, for the versions per product, I am guessing we only need the nightly versions as this report is for nightly crash trends.

Is this data exposed yet or do we need to call or write a service for it?

    
    

    
  
Schalk, we already had the discussion of what versions in here (around comment #70) and camo to the conclusion that we want this Nightly and Aurora, i.e. for those that get builds every day.

    
    

    
  
The data source only includes nightly and aurora data.

    
    

    
  
The data is exposed for the graphs. As to whether or not we expose a list of all current active versions of nightly and aurora for each product, I don't think we do. I can provide this service if that's what you're looking for.

    
    

    
  
I've updated my repository request with the needed service.

    
  
Blocks: 743659

    
  
Blocks: 743660

    
  
Target Milestone: 5 → 6

    
  
Target Milestone: 6 → 7

    
    

    
  
Commits pushed to master at https://github.com/mozilla/socorro

https://github.com/mozilla/socorro/commit/25f78b19d65bfd900f83ccd7390c860dd406e103
Bug 640238

This patch adds the backend functionality necessary to provide graph
data from the database server. The user should at least provide
basic information but the system will try to derrive the correct
information based on what the user does not input.

https://github.com/mozilla/socorro/commit/fac8301ba3ffeef5e2254f413d4c7c7ddb49b816
Bug 640238 - Final touches to integrate front end and backend together.

https://github.com/mozilla/socorro/commit/11458fe97646526367ba9c7c807c6d2156f51dc9
Bug 640238 - Adding service to allow the selection of product versions.

https://github.com/mozilla/socorro/commit/e693515f92fb03c087c9288e693937a9753c7ab6
Bug 640238 - Minor modifications to work with the javascript provided.

https://github.com/mozilla/socorro/commit/c6121aa9a61d59fdd6df52a18e4526896437d9f1
Merge pull request #511 from brandonsavage/nightly-crashes

Bug 640238 - Nightly Crash Trends

    
  
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED

    
  
Target Milestone: 7 → 8

    
    

    
  
On dev it appears that the title is not dynamically updating - it perpetually reads with the product/version that was originally loaded - in this case "Crash Trends Report For Firefox 15.0a1."
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
argh .. comment 88 was made in the wrong bug. bumping back to resolved fixed.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED

    
    

    
  
Bumping this to verified - in our discussion today we agreed that this is in excellent shape to ship. There are known (and surely unknown) bugs/feature enhancements that will need to be iterated on. Let's get this into our users hands and get some lovely eyes on this new report.

Verified on stage.
Status: RESOLVED → VERIFIED

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: