Closed
Bug 850450
Opened 12 years ago
Closed 12 years ago
Longitudinal recording of build ID
Categories
(Firefox Health Report Graveyard :: Client: Desktop, defect, P1)
Firefox Health Report Graveyard
Client: Desktop
Tracking
(firefox21+ fixed, firefox22+ fixed)
RESOLVED
FIXED
Firefox 22
People
(Reporter: gps, Assigned: gps)
References
Details
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
rnewman
:
review+
bajaj
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
+++ 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.
Assignee | ||
Updated•12 years ago
|
Assignee: nobody → gps
Comment 1•12 years ago
|
||
I don't think this is a high priority at this point, but I'm open to counter-arguments.
Priority: -- → P4
Comment 2•12 years ago
|
||
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.
Assignee | ||
Updated•12 years ago
|
status-firefox21:
--- → affected
tracking-firefox22:
--- → ?
Assignee | ||
Comment 4•12 years ago
|
||
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...
Attachment #726788 -
Flags: review?(rnewman)
Comment 5•12 years ago
|
||
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•12 years ago
|
||
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.
Attachment #726788 -
Flags: review?(rnewman) → review+
Comment 7•12 years ago
|
||
The build IDs should only differ for XULRunner apps. Do we care about those?
Comment 8•12 years ago
|
||
(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•12 years ago
|
||
(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.
Assignee | ||
Comment 10•12 years ago
|
||
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}.
Attachment #726788 -
Attachment is obsolete: true
Attachment #726836 -
Flags: review?(rnewman)
Updated•12 years ago
|
Attachment #726836 -
Flags: review?(rnewman) → review+
Assignee | ||
Comment 11•12 years ago
|
||
Status: NEW → ASSIGNED
Whiteboard: [fixed in services]
Assignee | ||
Comment 12•12 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [fixed in services]
Target Milestone: --- → mozilla22
Assignee | ||
Comment 13•12 years ago
|
||
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.
Attachment #726836 -
Flags: approval-mozilla-aurora?
Updated•12 years ago
|
Updated•12 years ago
|
Attachment #726836 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Assignee | ||
Comment 14•12 years ago
|
||
Updated•12 years ago
|
Component: Metrics and Firefox Health Report → Client: Desktop
Flags: in-testsuite+
Product: Mozilla Services → Firefox Health Report
Target Milestone: mozilla22 → Firefox 22
Updated•6 years ago
|
Product: Firefox Health Report → Firefox Health Report Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•