<div dir="ltr">I provided a high level summary of the forked proposal in Bug 895030 here:<br><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=895030#c39">https://bugzilla.mozilla.org/show_bug.cgi?id=895030#c39</a><br>

<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 22, 2013 at 11:57 AM, Benjamin Smedberg <span dir="ltr"><<a href="mailto:benjamin@smedbergs.us" target="_blank">benjamin@smedbergs.us</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">On 7/20/2013 2:09 AM, Gijs Kruitbosch wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
4) Profile reuse risks *aren't* theoretical. For example, we run one-way upgrade routines in browserland based on a pref (see UI migration in nsBrowserGlue.js for gory details). We do get bugs reported from users who upgrade, get migrated, then "downgrade" the same profile and then later complain that we've busted them ( e.g. <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=871459" target="_blank">https://bugzilla.mozilla.org/<u></u>show_bug.cgi?id=871459</a> ) and literally go on to suggest we should have migrated them (well, we did, really...).<br>


</blockquote></div>
This is one of the issues we originally identified as problematic when we originally moved to rapid release. IIRC, the proposed rule at the time is that any changes to data formats or migration should do reasonble things across all four of our channels and not leave users completely broken. That said, it is considered ok to do a one-time migration and "fork" the data. If the user goes back to the old version, they'll get the old data/settings, and get the new data/settings again on the newer channels.<br>


<br>
If this isn't actually happening in practice, or there are issues not covered by this general policy, I'd like to understand them; and if this policy isn't actually written down anywhere, we should probably do that.<div class="im">

<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I think we should consider the 'keep track of the default profile (but not the list of profiles!) per-install, and if one hasn't been used for that channel, create it.' option. We could tell people what happened on the first-run page, and, on their own head be it, give them the option to use the same default profile as for their regular install.<br>


</blockquote></div>
Because this conversation forked into bug 895030, I'd like to repeat what I said in there. I think that the following use cases are critical:<br>
<br>
A:<br>
<br>
* A user is using release and reports a bug having to do with some kind of profile data (extensions installed, bookmarks, settings, whatever)<br>
* We believe we've fixed it and the fix is available in Nightly/Aurora/whatever<br>
* We ask them to download the build with the fix and run it with their existing profile to check<br>
<br>
B:<br>
<br>
* A user is using a release build. They want to help Mozilla and we ask them to use Beta instead as their primary browser.<br>
* The users bookmarks, extensions, and settings should be available without any special action.<br>
<br>
I understand that there are cases, especially for web developers and people who cross branches all the time, where having a profile per channel branding makes more sense, but I *suspect* that this is the minority case and it will have serious side effects for the scenarios I listed.<br>


<br>
Given this, I think that it may make sense to keep a default profile per-install, but it does not make sense to create a new profile by default per-channel.<br>
<br>
My other strong interest here is to make sure that we don't expose anything like the current profile manager to users who only use release builds.<br>
<br>
--BDS<div class=""><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" target="_blank">https://mail.mozilla.org/<u></u>listinfo/firefox-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Thanks,<br>Brian R. Bondy
</div></div></div>