<div dir="ltr"><div style="font-size:12.8000001907349px">Meeting attendees: Vladan Djeric, Benjamin Smedberg, Georg Fritzsche, Mark Reid, Roberto Vitillo, Brendan Colloran, Alessio Placitelli</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px"><ul><li style="margin-left:15px">Benjamin explained that the primary motivation behind unified pings is reducing latency of FHR submissions on release and beta channels, as well as eliminating existing data quality issues</li><li style="margin-left:15px">We're still targeting Nightly 38 (uplift February 22) for merging FHR and Telemetry<br></li><li style="margin-left:15px">We decided, as a temporary compromise, that Firefox will maintain two sets of Telemetry/FHR measurements during a session:<br></li><ul><li style="margin-left:15px"><b>One set</b> represents all the measurements gathered during the session (current Telemetry behavior). Only one such ping will be sent per session (no more idle-daily ping)</li><ul><li style="margin-left:15px">This session ping will be in the new, unified ping format</li></ul><li style="margin-left:15px"><b>Second set</b> of measurements is reset whenever a new ping is created because a midnight boundary is crossed (local time) or because the environment has changed</li><ul><li style="margin-left:15px">These are the new sub-session pings</li><li style="margin-left:15px">On the server there will be a stitching job that runs every morning and generates sessions & days from the subsession pings</li></ul></ul><li style="margin-left:15px">The session pings are a temporary transition approach to prevent Mozilla losing the ability to do Telemetry analyses on the Nightly channel while the backend session-stitching code is being written and tested<br></li><ul><li style="margin-left:15px">Adapting about:telemetry is easy with the chosen approach. It will be messy when we exclusively have subsession pings</li><li style="margin-left:15px">Note: session-stitching will be very tricky for some types of measurements, e.g. UITelemetry</li></ul><li style="margin-left:15px">We discussed recreating session pings on the client by doing client-side session stitching instead, but decided keeping two sets of measurements is simpler and the memory overhead on Nightly is probably acceptable</li><li style="margin-left:15px">The Telemetry dashboard can easily be re-implemented using sub-session pings</li><ul><li style="margin-left:15px">Per-session measurements should not be reset when a new sub-session ping is created. The per-session measurements should <b>only</b> be reported in the last ping of the session</li><li style="margin-left:15px">Most other Perf-team Telemetry dashboards can be fed from sub-session pings</li><li style="margin-left:15px">We can maintain the current dashboard fed from session-pings for the time being</li></ul><li style="margin-left:15px">Mark explained the plans for the unified Telemetry/FHR server:</li><ul><li style="margin-left:15px">For Nightly & Aurora channels (low data volume), the server will store submissions from each client (clientID) in a separate file</li><ul><li style="margin-left:15px">This should make it straightforward to find all the subsessions belonging to the same session or to re-construct measurements by calendar day</li></ul><li style="margin-left:15px">On Beta & Release, there are two options:</li><ol><li style="margin-left:15px">Pick 1% of all users and store their pings per-ClientID, do the same for Experiments participants<br></li><li style="margin-left:15px">Track the storage locations of all pings on beta/release in a database and make it easy to get a list of locations by clientID</li></ol></ul></ul></div><span style="font-size:12.8000001907349px">Todos:</span><div style="font-size:12.8000001907349px"><ul><li style="margin-left:15px"><b>Vladan: </b>Estimate memory overhead of maintaining 2 sets of measurements in Telemetry<br></li><ul><li style="margin-left:15px">See my other message from today</li></ul><li style="margin-left:15px"><b>Mark Reid:</b> provide timeline for the by-ClientID server API<br></li><li style="margin-left:15px"><b>Vladan and Georg:</b> figure out details of implementing the session ping (e.g. how to deal with mid-session environment changes in the session ping)<br></li><li style="margin-left:15px">Open questions: how to deal with missing session fragments, session stitching rules by data type, FHR stitching rules, owners for the session and fhr-stitching rules/code</li></ul></div></div>