<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 27, 2015 at 3:18 PM, Brendan Colloran <span dir="ltr"><<a href="mailto:bcolloran@mozilla.com" target="_blank">bcolloran@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* Vlad, you mention "A single missing or corrupted fragment in a long<br>
<span>session means we won't be able to recreate the session. </span></blockquote><div><br></div><div>As Georg said in his reply, there were 2 bugs causing missing clientIDs. Unlike FHR, most Telemetry analyses are done with Nightly data, so Telemetry is more vulnerable to someone landing a patch that breaks "stitching" (e.g. breaks clientID reporting) for a few days.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* If I'm reading you proposal correctly, you're not proposing any<br>
changes to the data that will be collected by FHR (or telemetry?) or<br>
any changes to the way FHR data will be binned and aggregated-- you're<br>
just advocating for a more conservative roll out plan, yes?<br></blockquote><div><br></div><div>That's right. Basically I'm suggesting we preserve current Telemetry semantics in the new unified ping until the session stitching on the backend is ready and tested. I'm not proposing any alterations to FHR plans, except possibly a less aggressive schedule for making client-side changes -- I'm not sure what the timelines are around switching FHR to the unified ping.</div><div> </div><div>Vladan</div></div></div></div>