If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Add telemetry for MOZ_UPDATER

RESOLVED FIXED in Firefox 57

Status

()

Toolkit
Telemetry
P3
normal
RESOLVED FIXED
a month ago
4 days ago

People

(Reporter: rstrong, Assigned: agashlin)

Tracking

unspecified
mozilla57
Points:
1
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox57 fixed)

Details

Attachments

(2 attachments, 3 obsolete attachments)

MOZ_UPDATER is a build config option that distros typically use and whether it is enabled or not is stored in AppConstants.jsm.
https://dxr.mozilla.org/mozilla-central/source/toolkit/modules/AppConstants.jsm#105

It isn't possible to add this to app update telemetry since app update isn't built when MOZ_UPDATER is false.

This will make it possible to determine if a client has app update for app update out of date analysis such as the dashboard.

It might also be useful for other analysis such as the updated ping or possibly crash reports since when the value is false it isn't one of our builds that clients use.

It might make sense to put it under build or perhaps under application besides channel.
Robert, just to clarify, is this data point for measuring how many 3rd party packaged builds (e.g. Linux distributions), that enable telemetry, disable the updater system?
Flags: needinfo?(robert.strong.bugs)
Points: --- → 1
Priority: -- → P3
Also: do you know if your team/other teams are planning to use the data?
per the app update out of date dashboard
https://telemetry.mozilla.org/update-orphaning/

approximately 15.2% of clients that fall into "Out of date, potentially of concern reason distribution" have never sent app update telemetry and are sending other telemetry data. It is believed that these are primarily distros and for the purpose of the dashboard we would like to know if these systems have a Firefox build that includes app update.

My team definitely. No plans at this time for other teams using this data.
Flags: needinfo?(robert.strong.bugs)
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #3)
> per the app update out of date dashboard
> https://telemetry.mozilla.org/update-orphaning/
> 
> approximately 15.2% of clients that fall into "Out of date, potentially of
> concern reason distribution" have never sent app update telemetry and are
> sending other telemetry data. It is believed that these are primarily
> distros and for the purpose of the dashboard we would like to know if these
> systems have a Firefox build that includes app update.
> 
> My team definitely. No plans at this time for other teams using this data.

Do you want/does anyone on your team want to take a stab at this? I can gladly review or support with directions for the implementation.

The entry should probably be added in the build portion of the environment section [1], along with an update to the documentation at [2] and test coverage [3]. After a patch is ready, a data-review should be requested (see [4]).

Side note: I just noticed that some prefs are mirrored in the "update" section of the environment as well. I think we should probably remove one of the copies.

[1] - http://searchfox.org/mozilla-central/rev/cd82cacec2cf734768827ff85ba2dba90a534c5e/toolkit/components/telemetry/TelemetryEnvironment.jsm#1286
[2] - http://searchfox.org/mozilla-central/source/toolkit/components/telemetry/docs/data/environment.rst
[3] - http://searchfox.org/mozilla-central/source/toolkit/components/telemetry/tests/unit/test_TelemetryEnvironment.js
[4] - https://wiki.mozilla.org/Firefox/Data_Collection
[5] - http://searchfox.org/mozilla-central/rev/cd82cacec2cf734768827ff85ba2dba90a534c5e/toolkit/components/telemetry/TelemetryEnvironment.jsm#188-189,1374-1375
Flags: needinfo?(robert.strong.bugs)
(In reply to Alessio Placitelli [:Dexter] from comment #4)
<snip>
> Side note: I just noticed that some prefs are mirrored in the "update"
> section of the environment as well. I think we should probably remove one of
> the copies.
Most of the telemetry for these prefs affect how update checks and applying updates happen which is tied to when the telemetry for these prefs is gathered so if one were removed I would prefer it were the ones in the environment. I also would prefer it if that were done in a separate bug.

needinfo ddurst to see if he can find someone that has time to do this.
Flags: needinfo?(robert.strong.bugs) → needinfo?(ddurst)
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #5)
> (In reply to Alessio Placitelli [:Dexter] from comment #4)
> I also would prefer it if that were done in a separate bug.

Filed bug 1395062.
To do which? bug 1395062 or this bug (or both)?
Flags: needinfo?(ddurst) → needinfo?(robert.strong.bugs)
(In reply to David Durst [:ddurst] from comment #7)
> To do which? bug 1395062 or this bug (or both)?

Just this bug, bug 1395062 is not yet actionable.
Got it.
Flags: needinfo?(robert.strong.bugs)
In regards to bug 1395062, no one as far as I know was involved at all with either the env or the build preferences and it would probably be better to have someone that was deal with those. Also, the prefs I care about are gathered by the app update telemetry since they are timing specific per comment #5
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #10)
> In regards to bug 1395062, no one
no one from app update that is

> as far as I know was involved at all with
> either the env or the build preferences and it would probably be better to
> have someone that was deal with those. Also, the prefs I care about are
> gathered by the app update telemetry since they are timing specific per
> comment #5
(Assignee)

Updated

24 days ago
Assignee: nobody → agashlin
(Assignee)

Comment 12

22 days ago
Created attachment 8903668 [details] [diff] [review]
Add telemetry for MOZ_UPDATER, environment.build.updater

A simple patch to add the presence/absence of MOZ_UPDATER to telemetry in the build portion of environment, it is a bool called "updater".
Attachment #8903668 - Flags: review?(alessio.placitelli)
Comment on attachment 8903668 [details] [diff] [review]
Add telemetry for MOZ_UPDATER, environment.build.updater

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

This looks good overall, thanks for the patch. Please address the feedback below and flag me again for review.


Please note that this also requires a data-review from a data peer (https://wiki.mozilla.org/Firefox/Data_Collection).

::: toolkit/components/telemetry/TelemetryEnvironment.jsm
@@ +1291,5 @@
>        vendor: Services.appinfo.vendor || null,
>        platformVersion: Services.appinfo.platformVersion || null,
>        xpcomAbi: Services.appinfo.XPCOMABI,
>        hotfixVersion: Services.prefs.getStringPref(PREF_HOTFIX_LASTVERSION, null),
> +      updater: AppConstants.MOZ_UPDATER,

nit: I would personally rename this to something like "updaterAvailable"

::: toolkit/components/telemetry/tests/unit/test_TelemetryEnvironment.js
@@ +402,5 @@
>        Assert.ok(checkString(data.build.architecturesInBinary));
>      }
>    }
> +
> +  Assert.equal(data.build.updater, true);

Instead of |true|, let's check against AppConstants.MOZ_UPDATER. Let's also add a proper message to this assertion: it will make debugging easier if this suddenly starts to break.
Attachment #8903668 - Flags: review?(alessio.placitelli) → feedback+
Georg, do you have an opinion about this? Should the new property live in the environment/build?
Flags: needinfo?(gfritzsche)
(Assignee)

Comment 15

18 days ago
Created attachment 8904650 [details] [diff] [review]
Add telemetry for MOZ_UPDATER, environment.build.updaterAvailable

Thanks! Name changed to updaterAvailable, and I added a message to the assertion.

> Please note that this also requires a data-review from a data peer
> (https://wiki.mozilla.org/Firefox/Data_Collection).

I've written up what seems to be needed, following the document mentioned on bug 1380256 comment 21, is it best to just attach that and r? Rebecca on the patch once I get an r+ from you?
Attachment #8903668 - Attachment is obsolete: true
Attachment #8904650 - Flags: review?(alessio.placitelli)
Comment on attachment 8904650 [details] [diff] [review]
Add telemetry for MOZ_UPDATER, environment.build.updaterAvailable

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

(In reply to Adam Gashlin [:agashlin] from comment #15)
> I've written up what seems to be needed, following the document mentioned on
> bug 1380256 comment 21, is it best to just attach that and r? Rebecca on the
> patch once I get an r+ from you?

Thanks for the patch Adam, this looks good! I think you're good to request a data-review now.
Before landing the patch however, let's wait for :gfritzsche to clear the ni.
Attachment #8904650 - Flags: review?(alessio.placitelli) → review+
(Assignee)

Comment 17

17 days ago
Comment on attachment 8904650 [details] [diff] [review]
Add telemetry for MOZ_UPDATER, environment.build.updaterAvailable

Requesting data review, I've filled out a form with the required information at:

https://docs.google.com/document/d/154O2LOTu9GsOIyxYfwonsPUWN18JJBcE94yQrmnpRQY/edit?usp=sharing
Attachment #8904650 - Flags: review?(rweiss)

Comment 18

15 days ago
Comment on attachment 8904650 [details] [diff] [review]
Add telemetry for MOZ_UPDATER, environment.build.updaterAvailable

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

Can you please amend this bug with a file attachment for the contents in the Google doc?  Those responses are not publicly visible. 

1) Is there documentation that describes the schema for the ultimate data set available publicly, complete and accurate? 
Yes, this will follow standard UT documentation.

2) Is there a control mechanism that allows the user to turn the data collection on and off? (Note, for data collection not needed for security purposes, Mozilla provides such a control mechanism)  
Yes, the Telemetry opt-out.

3) If the request is for permanent data collection, is there someone who will monitor the data over time?
Yes, rstrong

4) Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under? 
This is category 1 information.

5) Is the data collection default-on or default-off? 
Default on, all channels, all locales

6) Does the instrumentation include the addition of any new identifiers (whether anonymous or otherwise; e.g., username, random IDs, etc. See the appendix for more details)? 
No

7) Is the data collection covered by the existing Firefox privacy notice? If unsure: escalate to legal.
Yes

8) Does there need to be a check-in in the future to determine whether to renew the data? (Yes/No) No
Attachment #8904650 - Flags: review?(rweiss) → review+
(Assignee)

Comment 19

15 days ago
Created attachment 8905719 [details]
Request for Data Collection Review

(In reply to Rebecca Weiss from comment #18)
> Comment on attachment 8904650 [details] [diff] [review]
> Add telemetry for MOZ_UPDATER, environment.build.updaterAvailable
> 
> Review of attachment 8904650 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Can you please amend this bug with a file attachment for the contents in the
> Google doc?  Those responses are not publicly visible.

Good point, attached
(Assignee)

Comment 20

15 days ago
Created attachment 8905720 [details]
Request for Data Collection Review for updaterAvailable

Reformatted a table that was confusing in the plain text export
Attachment #8905719 - Attachment is obsolete: true
status-firefox57: --- → fix-optional
Sorry for the delay here.
This is intending to do permanent data collection which looks like generally useful information.
The environment seems like the right place.
Flags: needinfo?(gfritzsche)
(Assignee)

Comment 22

5 days ago
Created attachment 8909367 [details] [diff] [review]
Add telemetry for MOZ_UPDATER, environment.build.updaterAvailable, proper patch

Updated patch with proper hg header, carrying forward r+ as the content of the patch is identical to what was reviewed.
Attachment #8904650 - Attachment is obsolete: true
Attachment #8909367 - Flags: review+
(Assignee)

Updated

5 days ago
Keywords: checkin-needed

Comment 23

5 days ago
bugherderlanding
https://hg.mozilla.org/integration/mozilla-inbound/rev/937a6f3af2bd
Flags: in-testsuite+
Keywords: checkin-needed

Comment 24

4 days ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/937a6f3af2bd
Status: NEW → RESOLVED
Last Resolved: 4 days ago
status-firefox57: fix-optional → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
You need to log in before you can comment on or make changes to this bug.