640237 - Get chofmann's rank compare (between versions) reports into Socorro

Status: RESOLVED WONTFIX

(Socorro :: Webapp, task)

Description

[Robert Kaiser]

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 rank comparison reports chofmann has in http://people.mozilla.org/~chofmann/crash-stats/ (compare-rank-*.txt in the dated subdirs).

chofmann will fill in further details on that.

Comment 1

[chris hofmann]

I think we have all the date for this just need to figure out how to make the reports.

admin panel work will need to be done to specify which releases we want comparisons done for.

I'm leverging this kind of release specification to run several of the reports including the rank comparison report

 
TRUNK=4.0b13pre
LASTTRUNK=4.0b12pre
LASTBETA=4.0b12
OLDERBETA=4.0b11
LASTSHIPPING=3.6.14
OLDERSHIPPING=3.6.13

Comment 2

[chris hofmann]

so the way to read something like

http://people.mozilla.org/~chofmann/crash-stats/20110308/compare-rank-4.0b12-4.0b11-4.0b13pre-3.6.14.txt

is 

the top mozalloc_abort crashes are in b12 but are not/found in the other releases.

GraphWalker is #6 in beta12, #24 in b11, #30 on mozilla-central, and not found in 3.6.x

these rankings come from the previous 1 days worth of data.

list-4.0b12
.	list-4.0b11
.	.	list-4.0b13pre
.	.	.	list-3.6.14
.	.	.	.	Signatures

2	n/f	n/f	n/f mozalloc_abort(char const* const) bug 633445
3	n/f	n/f	n/f mozalloc_abort(char const* const) bug 626768
4	n/f	n/f	n/f mozalloc_abort(char const* const) bug 635482
5	n/f	24	n/f CheckStackAndEnterMethodJIT    bug595351,634543
6	24	30	n/f GraphWalker<scanVisitor> bug 500105,569688
7	51	2	12  bug vksaver.dll@0x3398 614966
8	20	14	n/f js::gc::MarkId  bug 615098
9	n/f	59	n/f mozalloc_abort(char const* const) bug 634913
10	136	3	10  vksaver.dll@0x3392  bug 614966

Comment 3

[Ludovic Hirlimann [:Usul]]

Can we make sure this becomes product agnostic ?

Comment 4

[Robert Kaiser]

Clarifying in the summary that this is comparison between versions, as we also compare on the base of time.

(In reply to comment #3)
> Can we make sure this becomes product agnostic ?

I think any implementation will be that, if only because we probably need the same for Fennec and Firefox (but someone told me there might be other products in existence). ;-)

Comment 6

[chris hofmann]

another alturnative to just one table that we constantly modify in the admin panel we could build on the idea of "predecessor releases" that we could set up as part of setting up each new release.

predecessor releases for 4.0b12 might look like

 - 4.0b12pre  (development release predecessor)
 - 4.0b11     (beta release predecessor)
 - 3.6.15     (major release predecessor)

then we could carry this information around and make it useful for many places where we show information for 4.0b12 or its crashes.

Comment 7

[Brandon Savage [:brandon]]

For the sake of time, moving off to 2.1.

Comment 8

[Schalk Neethling [:espressive]]

So, we basically want this:

http://people.mozilla.org/~chofmann/crash-stats/20110308/compare-rank-4.0b12-4.0b11-4.0b13pre-3.6.14.txt

Nicely laid out and formatted?

Comment 9

[chris hofmann]

yes, and we will need an admin pannel to set the releases for comparison, or maybe  use the nightly, aurora, beta, release channels.

Comment 10

[chris hofmann]

latest reports are at https://crash-analysis.mozilla.com/chofmann/20111022/compare-rank-8.0-v-others.txt

Comment 11

[Schalk Neethling [:espressive]]

Attachment: Prototype 1

Based on report here: https://crash-analysis.mozilla.com/chofmann/20111022/compare-rank-8.0-v-others.txt

Comment 12

[Schalk Neethling [:espressive]]

Attachment: Prototype 1 rev1

Comment 13

[chris hofmann]

rather than make the "n/f" boxes stand out it would be better to visually make these boxes fade to a background color.    the boxes we most want to be alerted to are where the baseline release is dramatically higher in ranking than the other releases.

that means we are likely to have a regression that needs to be investigated.  making these kind of lines in the report visually stand out would be helpful.

Comment 14

[Schalk Neethling [:espressive]]

Thanks for the feedback Chris

Comment 15

[Schalk Neethling [:espressive]]

(In reply to chris hofmann from comment #13)
> rather than make the "n/f" boxes stand out it would be better to visually
> make these boxes fade to a background color.    the boxes we most want to be
> alerted to are where the baseline release is dramatically higher in ranking
> than the other releases.
> 
> that means we are likely to have a regression that needs to be investigated.
> making these kind of lines in the report visually stand out would be helpful.

Which is the baseline release? According to the text on the report:

"left column is ranking in baseline release - other columns are ranking in comparision releases" - but, that does not seem correct as the most left column is simply numbered sequentially from 1 - n

Comment 16

[chris hofmann]

left column is the baseline release, meaning it is the one that has ranking 1 through N, the other comparision releases just show the ranking where they show up in the other releases.

Comment 17

[Schalk Neethling [:espressive]]

(In reply to chris hofmann from comment #16)
> left column is the baseline release, meaning it is the one that has ranking
> 1 through N, the other comparision releases just show the ranking where they
> show up in the other releases.

Ok, so looking at the following example:

list-8.0   list-10.0a1   list-9.0a2   list-7.0.1    list-6.0.2
2	   308	         28	      n/f	    n/f

list-8.0 is the baseline and then, list-10.0a1... is the comparison releases so, for there to be an 'alert' on the baseline release, one needs a scenario such as the following:

list-8.0   list-10.0a1   list-9.0a2   list-7.0.1    list-6.0.2
308	   2	         28	      n/f	    n/f

Thanks for the assistance in assisting me in understanding this.

Comment 18

[Robert Kaiser]

I also think the headers should not have the "list-" part in it, they should just use the version alone. We could make it clearer though that what we are displaying in those columns is topcrash ranks, though.

Comment 19

[chris hofmann]

yep.

Comment 20

[Schalk Neethling [:espressive]]

[:[e-mail]] Definitely, took those straight of the report txt file and, as I was not sure whether or not to leave those off, I left them there for now.

Can you confirm on my comments in comment 17?

Comment 21

[Robert Kaiser]

(In reply to Schalk Neethling from comment #20)
> Can you confirm on my comments in comment 17?

I think Chris should do this, as he's alerted on this anyhow and nobody knows that report better than him :)

Comment 22

[chris hofmann]

so for this scenario:

list-8.0   list-10.0a1   list-9.0a2   list-7.0.1    list-6.0.2
2	   308	         28	      n/f	    n/f

the regression has spiked to the #2 crash in in firefox 8.0 and we want to flag that.

the crash is around in 9.0a2 and 10.0a1 but it hasn't bumped in ranking, maybe due to us needng to get many users on the release before we see a volume increase.

Comment 23

[chris hofmann]

also, the alerting is not all that critical and a just a nice to have thing for the first iterations of the report. we could just skip it for now if it's too complicated.

Comment 24

[Schalk Neethling [:espressive]]

Thanks Chris, I am working on the front end aspects so, whoever writes the glue code will have to decide on the complexity of the alerts but, I am sure this is completely doable, I will just work on making these instantly regocnizable when one looks at the report.

So numbers closer to 0 is bad and further away from 0 is better.

Comment 25

[chris hofmann]

> So numbers closer to 0 is bad and further away from 0 is better.

yeah,  higher ranking crashes mean more crashes are seen relative to others.  #1 top crash is our worst crash.

Comment 26

[Schalk Neethling [:espressive]]

(In reply to chris hofmann from comment #23)
> also, the alerting is not all that critical and a just a nice to have thing
> for the first iterations of the report. we could just skip it for now if
> it's too complicated.

Do we only want to show 'alerts' in the baseline or thigh highest in the row? So even for comparison releases.

Comment 27

[Schalk Neethling [:espressive]]

Attachment: Prototype 1 rev2

Comment 28

[chris hofmann]

highlighting the baseline rank like in your Prototype 1 rev2 looks fine.

question about the signature column.  what does that checkbox, or little symbol, on the lefthand side of the signature field signify?

Comment 29

[Schalk Neethling [:espressive]]

Chris, it signafies that clicking on the link will open it in a new tab, will replace with a better external link icon unless, the user of this report would not care if the link is opened in the same window/tab, in which case, I can remove the icon.

My thoughts was just that, someone would maybe want to open the link without leaving the report page.

Comment 30

[chris hofmann]

new tab for all the links in the signature column would be my preference.

Comment 31

[Schalk Neethling [:espressive]]

Chris, mine to, will just update the icon to a better one that is more clear or, what is your thoughts on the current one?

Comment 32

[chris hofmann]

it looked like some kind of check box, hence my confusion.  I'm not sure we need an icon at all.  typically the use case for analysis is to open up this listing of the ranking, then open up links to individual signatures in other windows or tabs to dig deeper to see what is going on with that set of crashes.   the tabs are opened up using right click or a tool like the linky addon, so this just makes all that a bit easier and faster.

Comment 33

[Schalk Neethling [:espressive]]

Attachment: Prototype 1 rev3

Changed the icon, let me know what you think, maybe I can move it to the right side of the link text? Should be intuative but, let me know your thoughts. Thanks.

Comment 34

[Robert Kaiser]

Hmm, I don't like to suddenly have a single report that does open things in new tabs when we're not doing that in any other thing on Socorro. I mean, I'm middle-clicking those links usually anyhow (or right-click and selecting new tab) - unless in those cases where I want to go to the crash list and don't need the report any more, in which case I'd be unhappy if I need to manually close that other tab.
I'd vote for going with consistency and not opening in new tabs just because we don't do that anywhere else right now.

In addition, I think the green background for "not found" is not really needed, or do we really want to highlight those cells?

Comment 35

[Schalk Neethling [:espressive]]

[:[e-mail]] I get that, seeing that is not the standard the let's not do this here. As far as the green background on n/f Chris wanted it to, sort of fade away, in a sense but, that does not mean we have to have the green.

I can simply make the font color a light gray. Let me upload another revision with these changes and we can go from there.

Comment 36

[Schalk Neethling [:espressive]]

Attachment: Prototype 1 rev4

Removed external link and functionality as well as green background from n/f cells.

Comment 37

[Schalk Neethling [:espressive]]

Regarding the admin pannel, I am assuming this will be behind the admin link that required a login or, do you see this as part of the report page?

If it is behind the admin login, or even if it is not really, this seems to be 5 drop downs with the various FF version and a button to either just set, or set and run the report.

Comment 38

[Robert Kaiser]

(In reply to Schalk Neethling from comment #37)
> Regarding the admin pannel, I am assuming this will be behind the admin link
> that required a login or, do you see this as part of the report page?

Behind the login in the admin section. Let's do a new page for that, though and not put it in the already huge "branch sources" admin page, though.

Comment 39

[Robert Kaiser]

(In reply to Schalk Neethling from comment #36)
> Created attachment 570799 [details]
> Prototype 1 rev4
> 
> Removed external link and functionality as well as green background from n/f
> cells.

Oh, and I like this one.

BTW, how much higher does a rank need to be to be flagged as red?

Comment 40

[Schalk Neethling [:espressive]]

(In reply to Robert Kaiser (:[e-mail]) from comment #38)
> (In reply to Schalk Neethling from comment #37)
> > Regarding the admin pannel, I am assuming this will be behind the admin link
> > that required a login or, do you see this as part of the report page?
> 
> Behind the login in the admin section. Let's do a new page for that, though
> and not put it in the already huge "branch sources" admin page, though.

We con totally have a new page for that I am sure.

Comment 41

[Schalk Neethling [:espressive]]

(In reply to Robert Kaiser (:[e-mail]) from comment #39)
> (In reply to Schalk Neethling from comment #36)
>
> Oh, and I like this one.
> 
> BTW, how much higher does a rank need to be to be flagged as red?

Robert, there has no threshold been set yet so I guess it is best to let yourself or Chris decide on this one.

Comment 42

[Schalk Neethling [:espressive]]

Are these reports run on demand from the admin section or, configured via admin and then run via a cron?

Comment 43

[chris hofmann]

the are run on cron, using data from the previous day, and the releases are select by the equivalent of an admin panel.

Comment 44

[Schalk Neethling [:espressive]]

Attachment: Admin UI

Would this work for the admin UI?

Comment 45

[chris hofmann]

looks good.

Comment 46

[Robert Kaiser]

We of course could be smart and just compare the versions marked as "featured" for the front page - just not sure which of them should be the "baseline" then.

Chris, what threshold of rank change should we have for highlighting the baseline cell? Rising from #12 to #11 is probably not really significant enough, after all.

Comment 47

[chris hofmann]

(In reply to Robert Kaiser (:[e-mail]) from comment #46)
> We of course could be smart and just compare the versions marked as
> "featured" for the front page - just not sure which of them should be the
> "baseline" then.
> 
yes, we could do that.  I've been producing reports using each of the latest major versions in the field as a base line.  So we could just work off the list.

> Chris, what threshold of rank change should we have for highlighting the
> baseline cell? Rising from #12 to #11 is probably not really significant
> enough, after all.

right,  we could set a threshold like 20% or something for the highlighting.

Comment 48

[Schalk Neethling [:espressive]]

Chris and KaiRo, do we have UI sign off on this one?

Comment 49

[Robert Kaiser]

(In reply to Schalk Neethling from comment #48)
> Chris and KaiRo, do we have UI sign off on this one?

yes from my side.

Comment 50

[chris hofmann]

> Chris and KaiRo, do we have UI sign off on this one?  

I like kairo's suggestion of just using the featured releases.  that would mean we don't need this extra admin panel.

Comment 51

[Schalk Neethling [:espressive]]

Attachment: UI Source

Comment 52

[Brandon Savage [:brandon]]

This was a stretch bug when it was put on the milestone, but I wanted to make sure we were tracking it in the queue. Pushing out, since it will probably need another cycle to be complete.

Comment 53

[Schalk Neethling [:espressive]]

[:brandon] UI is in Socorro with some dummy data table as an example. I can either do a pull request to get this in or whatever else will work best for you.

https://espressive-dev.allizom.org/rankcompare/index

Comment 54

[Schalk Neethling [:espressive]]

(In reply to chris hofmann from comment #50)
> > Chris and KaiRo, do we have UI sign off on this one?  
> 
> I like kairo's suggestion of just using the featured releases.  that would
> mean we don't need this extra admin panel.

Where do you want this report linked from inside Socorro?

Comment 55

[Robert Kaiser]

(In reply to Schalk Neethling from comment #54)
> Where do you want this report linked from inside Socorro?

If it's available for any "current" release comparing against (other) featured releases, then it could be in the standard place in the dropdown selection for every version.

Comment 56

[[:jberkus] Josh Berkus]

This looks fairly straightfowards.  It will probably involve some new matviews, though.

Please Confirm: we are always going to be ranking only one day's worth of crashes, correct? 

Also, please note some limitations on what we can do in the database:

1) We can only cover Rapid Release versions (i.e. 5.0 and later), and not earlier versions, due to the change in how versions are tracked.

2) We will only be able to compute this back to the release of Socorro 2.2, when we began storing TCBS data in the new format (March, I believe).

Comment 57

[chris hofmann]

(In reply to [:jberkus] Josh Berkus from comment #56)
> This looks fairly straightfowards.  It will probably involve some new
> matviews, though.
> 
> Please Confirm: we are always going to be ranking only one day's worth of
> crashes, correct? 

That is all I'm looking at in the current reports.  One day is fine, although it would be nice to look at 3 and 5 day ranking as well.


> 
> Also, please note some limitations on what we can do in the database:
> 
> 1) We can only cover Rapid Release versions (i.e. 5.0 and later), and not
> earlier versions, due to the change in how versions are tracked.
>

That is ok.  We are just interested in copmparing the current set of latest releases. 

> 2) We will only be able to compute this back to the release of Socorro 2.2,
> when we began storing TCBS data in the new format (March, I believe).

That is ok too.

Comment 58

[[:jberkus] Josh Berkus]

This feature is being bumped to 2.4.2 because we have been unable to reach chofmann to get answers to some basic specification questions, according to Brandon.  Starting with:

1) This report appears to be ahistorical; that is, it always compares based on a window ending in today, rather than some arbitrary historical window.  Is this correct?

2) What is the size of the time window over which we are ranking for each version? 1 day?  3 days?  7 days?  

3) How should we handle rankings for product-versions which have passed their sunset date (e.g. Firefox 6.0)?  Do we present the rankings for today, or do we take the rankings from the final week of their availability?

Comment 59

[Robert Kaiser]

(In reply to [:jberkus] Josh Berkus from comment #58)
> 1) This report appears to be ahistorical; that is, it always compares based
> on a window ending in today, rather than some arbitrary historical window. 
> Is this correct?
> 
> 2) What is the size of the time window over which we are ranking for each
> version? 1 day?  3 days?  7 days?  

AFAIK, chofmann's current implementation only takes ranks for the last single day we have on file. I guess we could do other windows just like topcrash has, but if it simplifies things I think we should go for 1 day right now. Adding anything else can always be a followup.

> 3) How should we handle rankings for product-versions which have passed
> their sunset date (e.g. Firefox 6.0)?  Do we present the rankings for today,
> or do we take the rankings from the final week of their availability?

After their sunset date, I don't care much either way, let's do whatever is easier (we could even just blank out the report with some text that says we aren't calculating this data for this version any more). If we do the "final rankings" stuff, we just should make clear from when the data is.

Comment 60

[[:jberkus] Josh Berkus]

> AFAIK, chofmann's current implementation only takes ranks for the last
> single day we have on file. I guess we could do other windows just like
> topcrash has, but if it simplifies things I think we should go for 1 day
> right now. Adding anything else can always be a followup.

It does simplify things to only be from the current date.  I'll also only implement one day (currently), but I'll put a "window_size" in the matview design so that we could implement 3 and 7 day windows if the users decide it'll be helpful.

> After their sunset date, I don't care much either way, let's do whatever is
> easier (we could even just blank out the report with some text that says we
> aren't calculating this data for this version any more). If we do the "final
> rankings" stuff, we just should make clear from when the data is.

Hmmm.  Not sure the current UI has any way to display dates for rankings which are from dates other than yesterday.  For now I'll just grab yesterday, regardless of version sunset dates; we can modify that later if someone decides it's helpful.

Thanks!

Comment 61

[[:jberkus] Josh Berkus]

OK, waiting for devdb to reload so that I can test my code.

The query for this will look something like this:

WITH base_ranks AS (
SELECT product_name, version_string, signature, rank_report_count,
	signature_id
FROM rank_compare
	JOIN product_versions USING (product_version_id)
	JOIN signatures USING (signature_id)
WHERE product_version_id = 792
AND rank_report_count < 21
),
v2_ranks AS (
SELECT version_string, rank_report_count, signature_id,
	report_count, percent_of_total
FROM rank_compare
	JOIN product_versions USING (product_version_id)
	JOIN signatures USING (signature_id)
WHERE product_version_id = 780
),
v3_ranks AS (
SELECT version_string, rank_report_count, signature_id,
	report_count, percent_of_total
FROM rank_compare
	JOIN product_versions USING (product_version_id)
	JOIN signatures USING (signature_id)
WHERE product_version_id = 756
),
v4_ranks AS (
SELECT version_string, rank_report_count, signature_id,
	report_count, percent_of_total
FROM rank_compare
	JOIN product_versions USING (product_version_id)
	JOIN signatures USING (signature_id)
WHERE product_version_id = 818
)
SELECT base_ranks.product_name, base_ranks.version_string as base_version,
	base_ranks.signature, 
	base_ranks.rank_report_count as base_rank,
	base_ranks.report_count as base_count,
	base_ranks.percent_of_total as base_percent,
	v2_ranks.version_string as v2_version, 
	v2_ranks.rank_report_count as v2_rank,
	v2_ranks.report_count as v2_count,
	v2_ranks.percent_of_total as v2_percent,
	v3_ranks.version_string as v2_version, 
	v3_ranks.rank_report_count as v2_rank,
	v3_ranks.report_count as v2_count,
	v3_ranks.percent_of_total as v2_percent,
	v4_ranks.version_string as v2_version, 
	v4_ranks.rank_report_count as v2_rank,
	v4_ranks.report_count as v2_count,
	v4_ranks.percent_of_total as v2_percent
FROM base_ranks
	LEFT OUTER JOIN v2_ranks USING ( signature_id )
	LEFT OUTER JOIN v3_ranks USING ( signature_id )
	LEFT OUTER JOIN v4_ranks USING ( signature_id )
ORDER BY base_rank;

That produces a crosstab of the comparison ranks for the top-20 signatures for the chosen version, plus comparative rankings for each version selected by the user.  We can compare any 4 versions this way.

I know that looks like a brutal query, but notice how much repetition there is; you're basically repeating the same query text for each compared version.  A simple loop should do it.

Comment 62

[[:jberkus] Josh Berkus]

Oh, also, I'm including actual crash counts and percent-of-total in this just because I have the data.  If you can manage it, I think it would be nice for the users to have that data accessible somehow, maybe as a mouseover?

Comment 63

[[:jberkus] Josh Berkus]

Ok, adjusted portion of the query:

WITH base_ranks AS (
SELECT product_name, version_string, signature, rank_report_count,
	signature_id, report_count, percent_of_total
FROM rank_compare
	JOIN product_versions USING (product_version_id)
	JOIN signatures USING (signature_id)
WHERE product_version_id = 792
	AND rank_days = 1
AND rank_report_count < 21
),
v2_ranks AS (
SELECT version_string, rank_report_count, signature_id,
	report_count, percent_of_total
FROM rank_compare
	JOIN product_versions USING (product_version_id)
	JOIN signatures USING (signature_id)
WHERE product_version_id = 780
	AND rank_days = 1
),
v3_ranks AS (
SELECT version_string, rank_report_count, signature_id,
	report_count, percent_of_total
FROM rank_compare
	JOIN product_versions USING (product_version_id)
	JOIN signatures USING (signature_id)
WHERE product_version_id = 756
	AND rank_days = 1
),
v4_ranks AS (
SELECT version_string, rank_report_count, signature_id,
	report_count, percent_of_total
FROM rank_compare
	JOIN product_versions USING (product_version_id)
	JOIN signatures USING (signature_id)
WHERE product_version_id = 818
	AND rank_days = 1
)
SELECT base_ranks.product_name, base_ranks.version_string as base_version,
	base_ranks.signature, 
	base_ranks.rank_report_count as base_rank,
	base_ranks.report_count as base_count,
	base_ranks.percent_of_total as base_percent,
	v2_ranks.version_string as v2_version, 
	v2_ranks.rank_report_count as v2_rank,
	v2_ranks.report_count as v2_count,
	v2_ranks.percent_of_total as v2_percent,
	v3_ranks.version_string as v2_version, 
	v3_ranks.rank_report_count as v2_rank,
	v3_ranks.report_count as v2_count,
	v3_ranks.percent_of_total as v2_percent,
	v4_ranks.version_string as v2_version, 
	v4_ranks.rank_report_count as v2_rank,
	v4_ranks.report_count as v2_count,
	v4_ranks.percent_of_total as v2_percent
FROM base_ranks
	LEFT OUTER JOIN v2_ranks USING ( signature_id )
	LEFT OUTER JOIN v3_ranks USING ( signature_id )
	LEFT OUTER JOIN v4_ranks USING ( signature_id )
ORDER BY base_rank;

That assumes, of course, that you want to use the report_count and percent_of_total.  If you don't, then:



WITH base_ranks AS (
SELECT product_name, version_string, signature, rank_report_count,
	signature_id
FROM rank_compare
	JOIN product_versions USING (product_version_id)
	JOIN signatures USING (signature_id)
WHERE product_version_id = 792
	AND rank_days = 1
AND rank_report_count < 21
),
v2_ranks AS (
SELECT version_string, rank_report_count, signature_id
FROM rank_compare
	JOIN product_versions USING (product_version_id)
	JOIN signatures USING (signature_id)
WHERE product_version_id = 780
	AND rank_days = 1
),
v3_ranks AS (
SELECT version_string, rank_report_count, signature_id
FROM rank_compare
	JOIN product_versions USING (product_version_id)
	JOIN signatures USING (signature_id)
WHERE product_version_id = 756
	AND rank_days = 1
),
v4_ranks AS (
SELECT version_string, rank_report_count, signature_id
FROM rank_compare
	JOIN product_versions USING (product_version_id)
	JOIN signatures USING (signature_id)
WHERE product_version_id = 818
	AND rank_days = 1
)
SELECT base_ranks.product_name, base_ranks.version_string as base_version,
	base_ranks.signature, 
	base_ranks.rank_report_count as base_rank,
	v2_ranks.version_string as v2_version, 
	v2_ranks.rank_report_count as v2_rank,
	v3_ranks.version_string as v2_version, 
	v3_ranks.rank_report_count as v2_rank,
	v4_ranks.version_string as v2_version, 
	v4_ranks.rank_report_count as v2_rank
FROM base_ranks
	LEFT OUTER JOIN v2_ranks USING ( signature_id )
	LEFT OUTER JOIN v3_ranks USING ( signature_id )
	LEFT OUTER JOIN v4_ranks USING ( signature_id )
ORDER BY base_rank;

Comment 64

[Brandon Savage [:brandon]]

This bug was a target for 2.4.1, but due to slower-than-expected progress on signature summaries needs to be pushed out. It's the top priority for 2.4.2.

Comment 65

[[:jberkus] Josh Berkus]

Should I keep the database changes in 2.4.1?

The advantage of keeping the database changes is that once you deploy the UI code, we'll already have data and history without backfilling.

The disadvantage is that it'll be annoying if it turns out that we need to change the matview structure.

Thoughts?

Comment 66

[Brandon Savage [:brandon]]

This has been detargeted for the time being.

Comment 67

[Brandon Savage [:brandon]]

I didn't see this in our Q2 goals list. Is this bug still wanted, and what's its priority?

Comment 68

[Robert Kaiser]

(In reply to Brandon Savage [:brandon] from comment #67)
> I didn't see this in our Q2 goals list. Is this bug still wanted, and what's
> its priority?

It's OK from my side to consider this low priority for now, stuff like the GC and exploitable reports as well as anything we need for B2G is higher in priority from the CrashKill side right now.

Comment 69

[Lonnen :lonnen]

we are not investing in new, specific reports