Closed Bug 890650 Opened 11 years ago Closed 11 years ago

Investigate turning on rapid beta for Firefox

Categories

(Socorro :: Infra, task)

Product:
Socorro
Component:
Infra
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: kairo, Assigned: selenamarie)

Details

As we have switched to releasing two betas per week for Firefox now, we should see if turning on rapid beta support gives us more helpful graphs and topcrash reports by counting all beta users together. AFAIK, we'd still get the separate reports for every single beta in addition, right?

Do we have the same data as on prod on stage as well so that we can see if anything breaks if we do this, or if it's helpful at all?

IIRC, all that needs to be done to enable this is to set a config var for the minimum version to which rapid beta should be applied, which would be 23 in this case. Would we need to backfill some reports as well to see useful data?
Assignee: nobody → sdeckelmann
I've updated the value on stage and am running a backfill of materialized views to verify that nothing breaks. 

We already have rapid beta turned on for B2G, so this backfill is being run out of an abundance of caution, as it appears that things are ok for B2G already. 

Sorry for the delay!
In testing this on stage, I needed to set the rapid_beta_id for products that had been added to Socorro before I added the beta: 

> update product_versions set rapid_beta_id = 1811 where product_version_id IN ( select product_version_id from product_versions where product_name = 'Firefox' and version_string ~ '23' and build_type = 'Beta' and is_rapid_beta is False ) ; 

Will need to do something similar in prod.
I've confirmed that https://crash-stats.allizom.org/topcrasher/products/Firefox/versions/23.0b exists in stage. 

Now applying the data change to prod. 

Future runs of ftpscraper should do the correct thing with new versions.
Worked in stage, but got this error on prod: 

PL/pgSQL function backfill_matviews(date,date,boolean,interval) line 67 at SQL statement
INFO:  crashes by user
ERROR:  null value in column "product_version_id" violates not-null constraint
DETAIL:  Failing row contains (null, lin, 1, 2013-08-19, 2013-08-25, 0, 296).
CONTEXT:  SQL statement "INSERT INTO crashes_by_user_build

Investigating...
Note that given a number of weeks have passed, 23.0b isn't the interesting version now, but 24.0b is, actually. We really need this for 24 only on prod, as 23 final has been shipped already anyhow.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #5)
> Note that given a number of weeks have passed, 23.0b isn't the interesting
> version now, but 24.0b is, actually. We really need this for 24 only on
> prod, as 23 final has been shipped already anyhow.

Thanks for letting me know. Doesn't help with this bug, unfortunately.
Commit pushed to master at https://github.com/mozilla/socorro

https://github.com/mozilla/socorro/commit/479a69d0e2341e25ea719655fda6414619d527e3
Merge pull request #1449 from selenamarie/bug890650-crashes-by-user-build

Fixes Bug890650 crashes by user build
This made it to production with release 57. Selena, I assume you need to run backfilling before this can be marked as resolved?
Target Milestone: --- → 57
:KaiRo would you like any additional backfilling? The change went out with last week's release, so the past week's worth of data includes rapid beta.
Flags: needinfo?(kairo)
Target Milestone: 57 → ---
Target Milestone: --- → 57
I'm slightly confused as to how this works right now. Looking at https://crash-stats.mozilla.com/daily?form_selection=by_version&p=Firefox&v=24.0b8&v=24.0b7&v=24.0b6&v=24.0b&hang_type=any&os=Windows&os=Mac+OS+X&os=Linux&date_range_type=report&date_start=2013-08-22&date_end=2013-09-05&submit=Generate I see a 2013-08-26 entry for 24.0b that looks reasonable, the newer ones look like they are only summing up b7 and b8 and leaving out b6 (and earlier I guess). Is that expected?
Flags: needinfo?(kairo)
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #10)
> I'm slightly confused as to how this works right now. Looking at
> https://crash-stats.mozilla.com/
> daily?form_selection=by_version&p=Firefox&v=24.0b8&v=24.0b7&v=24.0b6&v=24.
> 0b&hang_type=any&os=Windows&os=Mac+OS+X&os=Linux&date_range_type=report&date_
> start=2013-08-22&date_end=2013-09-05&submit=Generate I see a 2013-08-26
> entry for 24.0b that looks reasonable, the newer ones look like they are
> only summing up b7 and b8 and leaving out b6 (and earlier I guess). Is that
> expected?

Yes -- the spec and code indicate that only 2 weeks work of betas are to be considered in the calculation.
I think this bug is now resolved. The feature is deployed. If there are issues with how it is working, let's open new bugs.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.