We need to do a number of changes to make the PostgreSQL database handle ESRs correctly: 1) add ESR to the several release channel tables 2) Modify update_product_versions() to rewrite the channel for ESR builds. 3) Change the sunset date on ESRs to match releases 4) Change update_reports_clean to handle ESRs correctly. 5) Change version_sort() to sort ESRs after Releases 6) Change update_adu to handle ESRs correctly. NOTE: This is waiting on Metrics pushing ESRs. 7) Verify that all matviews include ESR counts. 7)a) fix any matviews which don't. NOTE: some matviews will not be possible to test due to the nature of the data from ESR crashes. HangReport, for example. 8) verify that data is being displayed properly on the interface. As of 2/21, most of the above is done in draft form.
Database changes have been deployed on crash-stats-dev. Adrian is current testing whether all functionality is operating as expected.
Notes for QA testing: verify that ESR releases appear and display summaries, listings, and statistics in all interfaces in the same way other releases do.
I'm not sure if this is expected however I'm not seeing OS or Uptime statics for this esr crash signature - https://crash-stats.allizom.org/report/list?product=Firefox&version=Firefox:10.0.1esr&query_search=signature&query_type=contains&reason_type=contains&date=03/05/2012%2019:07:43&range_value=4&range_unit=weeks&hang_type=any&process_type=plugin&plugin_field=filename&plugin_query_type=exact&do_query=1&signature=hang%20|%20WaitForMultipleObjectsEx%20|%20RealMsgWaitForMultipleObjectsEx
We only backfilled to 2/22. That crash report is on 2/20, which is why it doesn't show up consistently.
bumping to resolved per comment 4
QA verified on stage - automation is passing - manual bfts pass.