
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Hi,</div><div><br></div><div>thanks for the write-up. I would like to mention that we should come to a conclusion on this soon if we still want to make 38 as this blocks a big part of the fundamental client changes.</div><br><div><div>On 24 Jan 2015, at 07:35, Vladan Djeric <<a href="mailto:vdjeric@mozilla.com">vdjeric@mozilla.com</a>> wrote:</div><blockquote type="cite"><div dir="ltr"><div><b>So first off, let me describe my intepretation of the <a href="https://docs.google.com/document/d/1IGpzsYGi_sq3YFQDAPyKOkU_BKvXAC95fZYA2i4ceVs/edit#">current unification proposal</a>:</b></div><div><ul><li><font color="#ff0000">Whenever a new ping is started, all the FHR & Telemetry measurements for the current session will be reset</font></li></ul></div></div></blockquote>My assumptions was that we will not reset. There is Telemetry data that is not meaningful when reset, so i could only imagine opt-in for specific probes to be reset (e.g. add a “daily” property to histograms if we need that).</div><div>Do we have a good argument for resetting all of them in the first place? Most of your concerns result from that.</div><div><blockquote type="cite"><div dir="ltr"><div><ul><li>In the new system, Firefox starts collecting a new ping whenever:</li><ol><li>a new Firefox session is started</li><li>a new day has begun (not sure if it's every 24 hours of uptime, or if it's based on local time e.g. midnight local time)</li></ol></ul></div></div></blockquote>That was a partially open question, midnight local time is what we will do unless there is useful counter arguments.</div><div><blockquote type="cite"><div dir="ltr"><div><ul><li>There's overhead from sending a new ping for each mid-session environment change</li><ul><li>There's also a small privacy issue with creating ordered, fine-grained reports of user actions, e.g. when a user goes through their add-ons list and disables 5 addons, we report each user action</li><li>Either coalesce successive environment-change pings, or carefully vet which mid-session environment changes generate a new ping</li></ul></ul></div></div></blockquote>If that is a problem, we can always consider coalescing as an incremental improvement on the current plan.</div><div><br><blockquote type="cite"><div dir="ltr"><div>I'd like to propose that we implement the following modifications to the FHR/Telemetry v4 document:<br><ol><li>Do not reset <u>Telemetry</u> measurements when a session crosses the 24-hour boundary</li><ul><li>Continue to "reset" Telemetry measurements when we start a new session</li><li>There's no need to reset Telemetry on most environment changes (e.g. amount of memory installed) since those can't happen without a Firefox restart anyway.</li></ul><li>Record mid-session environment changes (add-ons and TelemetryExperiments) in a special section in the ping.</li><ul><li>For each such environment change, document the change in the section and also attach a snapshot of the Telemetry & FHR data at the time of the change</li><li>After the snapshot is saved, reset Telemetry and FHR measurements for the current session. In other words, snapshot & then build up a diff<br></li><li>For each additional environment change during the same session, just repeat and append to the new section<br></li><li>Telemetry backend scripts (dashboard, regression detector etc) can just ignore experiment/add-on change pings</li></ul></ol></div></div></blockquote>What would the snapshots diff against? Diffing going back from the final ping? Also, any diffing client-side adds complexity and potential issue - i’d prefer to avoid that if possible.</div><div><br></div><div><br></div><div>Georg</div></body></html>