Data issues with cloned profiles

[Mark Reid]

Re: duplicates - yes, we de-duplicate in the ingestion pipeline, so sending
a few duplicate submissions is preferable to not sending at all.

On Tue, Feb 6, 2018 at 1:10 AM, Georg Fritzsche <gfritzsche at mozilla.com>
wrote:

> Once we get past some initial issues, the per-channel-profiles should make
> some data work easier, so this is great to hear.
> We briefly discussed this before; the most immediate impact would be a
> potential bump in user numbers on some channels.
>
> On a first pass, these come to my mind:
> - We need to make sure that the client id gets reset, as this for us is a
> profile identifier. This means: resetting the pref toolkit.telemetry.cachedClientID,
> clearing datareporting/state.json
> - We need to clear datareporting/session-state.json
> - Unsent pings being sent from the new profile sounds right. We'd probably
> rather have duplicates. @mreid to confirm?
> - What about the profile age (ProfileAge.jsm, times.json)? We use this to
> judge the "age" of a user. I could see arguments for both retaining and
> clearing.
> - We should track that this is a "per-channel-profile copy" in Telemetry.
> Then we can trace down oddities etc. This might live in the environment?
>
> Is there a document or bug tree that is tracking this work?
>
> Cheers,
> Georg
>
>
> On Mon, Feb 5, 2018 at 2:45 PM, Dave Townsend <dtownsend at mozilla.com>
> wrote:
>
>> A new feature we are targetting for Firefox 60 involves giving each
>> release channel a separate profile by default. In order to push users into
>> this situation on upgrade non-release channels will make a clone of the
>> release profile for use going forwards. Currently this is a complete copy
>> of all files and settings from the release profile which raises a couple of
>> immediate potential issues:
>>
>> The value of toolkit.telemetry.cachedClientID will be shared across
>> potentially many profiles. I could probably regenerate this for each cloned
>> profile if there is a procedure for doing this.
>>
>> Any unsent pings will be cloned and so may be sent as duplications. The
>> only way to avoid this would be to not clone the ping but that might mean
>> that those pings are never sent. I'm not sure which is preferable.
>>
>> Any other issues I'm not considering?
>>
>> _______________________________________________
>> Fx-data-dev mailing list
>> Fx-data-dev at mozilla.org
>> https://mail.mozilla.org/listinfo/fx-data-dev
>>
>>
>
> _______________________________________________
> Fx-data-dev mailing list
> Fx-data-dev at mozilla.org
> https://mail.mozilla.org/listinfo/fx-data-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/fx-data-dev/attachments/20180206/51a63a3b/attachment.html>