850450 - Longitudinal recording of build ID

Status: RESOLVED FIXED

(Firefox Health Report Graveyard :: Client: Desktop, defect, P1)

Description

[Gregory Szorc [:gps]]

+++ This bug was initially created as a clone of Bug #849947 +++

In bug 849947 (and elsewhere I believe), Metrics has asked for FHR to report per-day build ID information instead of merely reporting the last encountered build ID value. This bug will track that specific request.

Comment 1

[Mike Connor [:mconnor]]

I don't think this is a high priority at this point, but I'm open to counter-arguments.

Comment 2

["Saptarshi Guha[:joy]"]

This is related to Bug 850483  and is required for solving Bug 849947. If we don't include longitudinal buildID we can't know what buildid the installation was on when active on day D.

Note, this is temporary and this piece of information is not required once 849947 is resolved.

Hence it should be P1.

Comment 3

[Gregory Szorc [:gps]]

Saptarshi says this should be a P1. I agree.

Comment 4

[Gregory Szorc [:gps]]

Attachment: Record history of build ID, v1

This should do it!

I'm only capturing the application's build ID. Do we want the platform build ID as well? It's trivial to add...

Comment 5

["Saptarshi Guha[:joy]"]

I dont know the difference! The reason for this is because in pre-release version is not enough, buildid is like a version. So if comparative measures need to given to users in HealthReport who are on say Build B of Firefox Nightly, then we would like comparisons with other installations of Build B (or maybe B-1,B), and not with Firefox Nightly latest version.

Comment 6

[Richard Newman [:rnewman]]

Comment on attachment 726788 [details] [diff] [review]
Record history of build ID, v1

Review of attachment 726788 [details] [diff] [review]:
-----------------------------------------------------------------

Yes, submit the platform version, too. It'll be different for XULRunner apps.

::: services/healthreport/providers.jsm
@@ +147,5 @@
> +  version: 2,
> +
> +  fields: {
> +    version: {type: Metrics.Storage.FIELD_DAILY_DISCRETE_TEXT},
> +    appBuildID: {type: Metrics.Storage.FIELD_DAILY_DISCRETE_TEXT},

For the historical record: I don't think this needs an explicit 'gecko' in the name. We'll do something else on Android.

Comment 7

[(not currently active) Ted Mielczarek]

The build IDs should only differ for XULRunner apps. Do we care about those?

Comment 8

[Richard Newman [:rnewman]]

(In reply to Saptarshi Guha from comment #5)
> I dont know the difference! The reason for this is because in pre-release
> version is not enough, buildid is like a version. So if comparative measures
> need to given to users in HealthReport who are on say Build B of Firefox
> Nightly, then we would like comparisons with other installations of Build B
> (or maybe B-1,B), and not with Firefox Nightly latest version.

For that, version, updateChannel, and appBuildID will suffice: my current Nightly is 22.0a1, nightly, 20130310030906. I'm on the 2013-03-10 Nightly (about to relaunch!).

Comment 9

[Richard Newman [:rnewman]]

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #7)
> The build IDs should only differ for XULRunner apps. Do we care about those?

Yes: that's Fedora and Debian.

Comment 10

[Gregory Szorc [:gps]]

Attachment: Record history of build ID, v2

I added platformBuildID to the mix. While I was here, I noticed that the app version was being reported as "version." So, I changed it to "appVersion." And, we weren't recording platform version. So, why not, I also added platform version to the mix. We now have longitudinal history of all {app id, app version, platform id, platform version}.

Comment 11

[Gregory Szorc [:gps]]

https://hg.mozilla.org/services/services-central/rev/59e0077b1975

Comment 12

[Gregory Szorc [:gps]]

https://hg.mozilla.org/mozilla-central/rev/59e0077b1975

Comment 13

[Gregory Szorc [:gps]]

Comment on attachment 726836 [details] [diff] [review]
Record history of build ID, v2

[Approval Request Comment]
Bug caused by (feature/regressing bug #): FHR
User impact if declined: Metrics is unable to retrieve Aurora version usage over time.
Testing completed (on m-c, etc.): It's baked for a few days.
Risk to taking this patch (and alternatives if risky): It's no more risky than code that was already in the tree.
String or UUID changes made by this patch: None

This should have been part of the original FHR release. It was an oversight that we only recorded a version history, not a build ID history.

Having this recording will also enable us to understand when frankenfoxes occur.

Comment 14

[Gregory Szorc [:gps]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/c9a89c47a782