<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;"><br><div><div>On 27 Jan 2015, at 10:48, Vladan Djeric <<a href="mailto:vdjeric@mozilla.com">vdjeric@mozilla.com</a>> wrote:</div><div><br></div><blockquote type="cite"><div dir="ltr"><div>I think we should try to land the client-side changes gradually. <br><br></div>A rough sketch:<br><div><ol><li>Modify the server backend to accept Telemetry pings in the new JSON format (clientID, sessionID, sysinfo, env, etc). Bump version number.</li><ul><li>Also update the backend to parse E10S data from the Telemetry payload<br></li><li>Update dashboard code<br></li></ul><li>Modify client to send Telemetry pings in the new JSON format. Rip out the obsolete "idle-daily" Telemetry ping.<br></li><ul><li>Continue submitting Telemetry saved-session ping </li><li>Continue to upload FHR data separately</li></ul><li>Modify the Telemetry backend code to ignore all mid-session Telemetry pings.<br></li><li>Modify Telemetry client-side to create new pings on 24-hour boundaries. Do not reset any measurements in the middle of a session. Indicate the last ping of a session explicitly. Bump version number.</li><ul><li>This is essentially my earlier proposal, but as a (hopefully) temporary measure.</li><li>E10S child Telemetry code will have to be modified to create subsessions at the same time as parent</li></ul><li>Adapt Telemetry Experiments backend as needed<br></li><li>Modify Telemetry code to create new pings on environment change. Update Experiments code as needed<br></li><li>Modify backend to parse and store the new unified ping format. Stress test etc.</li><ul><li>All FHR backend functionality should be complete before the next step</li><li>The FHR user-day stitching code should be finished and tested with realistic loads</li></ul><li>Switch FHR to use the Telemetry upload mechanism, and switch over FHR & Telemetry to the new unified ping format. Reset FHR measurements on new pings. Bump version number</li><ul><li>At this point, the people working on the FHR backend can stabilize and improve the backend</li><li>After we have experience with handling the new ping semantics with FHR, we can move on to converting Telemetry in the next step<br></li></ul><li>Assuming success of step 7, write and test session stitching, extend FHR user-day stitching to Telemetry data, integrate new Telemetry subsession format with map-reduce and Spark analysis, dashboards, regression detector, etc.</li><ul><li>Lots of custom stitching rules, e.g. Background-Hang-Reporter data<br></li></ul><li>Change Telemetry to reset-on-new-ping semantics. Adapt existing probes. Bump version number.</li><ul><li><a href="about:telemetry">about:telemetry</a> will be a pain to convert. It will have to do client-side stitching using saved local pings, or display the subsession separately. Both are bad<br></li></ul><ul><li>fx-team's UITelemetry reporting will require some special
attention. It's very much session-based and there are no clear rules for
stitching it together from subsessions</li><li>Identify and fix one-per-session histograms<br></li><li>Document and publicize the new ping model for Telemetry probe authors<br></li></ul></ol><p>I think this gradual approach would allows us to focus on converting one backend at a time and to use the experience gained with FHR to convert Telemetry.</p><p>What do you think?</p></div></div></blockquote></div>The plan on its own sounds reasonable, but i see two problems:<div>* The goal is to land the unification in 38. I don’t think this is realistic with this incremental approach. </div><div>* We won’t plan on having a clear separation of the FHR data that we migrate to Telemetry (unless we would do some temporary separate implementation). E.g. some of the data is already in Telemetry.</div><div><br></div><div>Georg</div></body></html>