On 7/19/2013 1:21 PM, Anton Kovalyov wrote:
> So here I'm proposing adding another release channel, Firefox Developer, and put it somewhere in between Aurora and Nightly. The channel would update every week or so and use its own Profile directory.

On 19/07/13 22:21 , Anton Kovalyov wrote:
> So here I'm proposing adding another release channel, Firefox Developer, and put it somewhere in between Aurora and Nightly. The channel would update every week or so and use its own Profile directory.

On 7/19/13 1:29 PM, Gijs Kruitbosch wrote:
> On 19/07/13 22:21 , Anton Kovalyov wrote:
>> So here I'm proposing adding another release channel, Firefox
>> Developer, and put it somewhere in between Aurora and Nightly. The
>> channel would update every week or so and use its own Profile directory.
> What does "in between Aurora and Nightly" mean in terms of which
> repository it pulls changes from? m-c or m-a?

On 7/19/13 1:29 PM, Gijs Kruitbosch wrote:

> On 19/07/13 22:21 , Anton Kovalyov wrote:
>> So here I'm proposing adding another release channel, Firefox
>> Developer, and put it somewhere in between Aurora and Nightly. The
>> channel would update every week or so and use its own Profile directory.
> What does "in between Aurora and Nightly" mean in terms of which
> repository it pulls changes from? m-c or m-a?

On 19/07/2013 22:21, Anton Kovalyov wrote:
> 1. Users employing different Firefox channels to test Firefox itself. These people need ability to re-use the same profile across different channels.
>
> 2. Web and Firefox OS developers using Firefox both as their main browser and a tool for web development. These people need both stability of stable channels as well as ability to run latest tools.
>
> First group is covered relatively well today while the second group isn't. Tools like install-all-firefox [2] give us insight that ability to run multiple channels is a real issue. So here I'm proposing adding another release channel, Firefox Developer, and put it somewhere in between Aurora and Nightly. The channel would update every week or so and use its own Profile directory.

----- Original Message -----
> From: "Marco Bonardo" <mbon...@mozilla.com>
> But I suspect
> Aurora was the channel intended for Wed developers, it has almost latest
> technology and it's stable enough...

On 20/07/2013 6:21 AM, Anton Kovalyov wrote:
> Fitzgen, Gavin and myself chatted briefly today about bug 895030 [1]
> and my proposal to make Nightly use separate profile directory. So
> far I see two use cases for Nightly/Aurora builds:
>
> 1. Users employing different Firefox channels to test Firefox itself.
> These people need ability to re-use the same profile across different
> channels.
>
> 2. Web and Firefox OS developers using Firefox both as their main
> browser and a tool for web development. These people need both
> stability of stable channels as well as ability to run latest tools.
>
> First group is covered relatively well today while the second group
> isn't. Tools like install-all-firefox [2] give us insight that
> ability to run multiple channels is a real issue. So here I'm
> proposing adding another release channel, Firefox Developer, and put
> it somewhere in between Aurora and Nightly. The channel would update
> every week or so and use its own Profile directory.
>
> With this approach we won't mess with the first group users and give
> the second group ability to have it all: both stable browser for
> day-to-day use and latest and greatest tools for web and Firefox OS
> developers.

On 20/07/2013 8:16 AM, Anton Kovalyov wrote:
> On IRC (#devtools) this idea evolved into doing a separate build of
> Nightly with its own branding and profile. I'm don't know all the
> details on how branding, etc. works so I'll let gavin and/or dcamp to
> explain.

On 20/07/2013 2:34 PM, Anton Kovalyov wrote:
> On Jul 19, 2013, at 6:54 PM, Mark Hammond <skippy...@gmail.com

> <mailto:skippy...@gmail.com>> wrote:
>
>> On 20/07/2013 8:16 AM, Anton Kovalyov wrote:
>>> On IRC (#devtools) this idea evolved into doing a separate build of
>>> Nightly with its own branding and profile. I'm don't know all the
>>> details on how branding, etc. works so I'll let gavin and/or dcamp to
>>> explain.
>>
>> Isn't this going to lead to the following conversation:
>
> Not really. People who want to run Nightly as their main profile will be
> able to continue doing so. But people who want stable Firefox and latest
> tools will be able to download Developer build and run in alongside
> their main Firefox (stable or beta) with no additional work required.

On 2013-07-19, at 22:02, Mark Hammond <skippy...@gmail.com> wrote:

> On 20/07/2013 2:34 PM, Anton Kovalyov wrote:
>> On Jul 19, 2013, at 6:54 PM, Mark Hammond <skippy...@gmail.com
>> <mailto:skippy...@gmail.com>> wrote:
>>
>>> On 20/07/2013 8:16 AM, Anton Kovalyov wrote:
>>>> On IRC (#devtools) this idea evolved into doing a separate build of
>>>> Nightly with its own branding and profile. I'm don't know all the
>>>> details on how branding, etc. works so I'll let gavin and/or dcamp to
>>>> explain.
>>>
>>> Isn't this going to lead to the following conversation:
>>
>> Not really. People who want to run Nightly as their main profile will be
>> able to continue doing so. But people who want stable Firefox and latest
>> tools will be able to download Developer build and run in alongside
>> their main Firefox (stable or beta) with no additional work required.
>
> I'm a lot more comfortable with this if our position is explicitly that it's fine to use Firefox, Beta, Aurora and Nightly with your default profile and swap between them at will.  As long as we aren't suggesting that multiple profiles is a workaround for anything, I think that's fine.

On 20/07/2013 3:42 PM, Rob Campbell wrote:

> The danger is pretty much a theoretical risk, but one we don't want to inflict on developers just the same.

On 19/07/13 22:21 , Anton Kovalyov wrote:

> Fitzgen, Gavin and myself chatted briefly today about bug 895030 [1] and my proposal to make Nightly use separate profile directory. So far I see two use cases for Nightly/Aurora builds:
>
> 1. Users employing different Firefox channels to test Firefox itself. These people need ability to re-use the same profile across different channels.
>
> 2. Web and Firefox OS developers using Firefox both as their main browser and a tool for web development. These people need both stability of stable channels as well as ability to run latest tools.
>
> First group is covered relatively well today while the second group isn't. Tools like install-all-firefox [2] give us insight that ability to run multiple channels is a real issue. So here I'm proposing adding another release channel, Firefox Developer, and put it somewhere in between Aurora and Nightly. The channel would update every week or so and use its own Profile directory.
>
> With this approach we won't mess with the first group users and give the second group ability to have it all: both stable browser for day-to-day use and latest and greatest tools for web and Firefox OS developers.
>
> Thoughts?
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=895030
> [2] https://github.com/omgmog/install-all-firefox
>
> Anton
>

On 2013-07-20, at 2:09 AM, Gijs Kruitbosch <gijskru...@gmail.com> wrote:

> On 19/07/13 22:21 , Anton Kovalyov wrote:
>
> So, reading everything, I think this is tempting but not the right thing to do:

On 7/19/2013 9:54 PM, Mark Hammond wrote:
>
> q) oh, great - that means I can just use Nightly if I want all the
> Nightly goodness along with all the goodness of my regular profile?
> a) no, no, no!  You would be insane to do that!  Never do that!

On 7/20/2013 2:09 AM, Gijs Kruitbosch wrote:
>
> 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.
> https://bugzilla.mozilla.org/show_bug.cgi?id=871459 ) and literally go
> on to suggest we should have migrated them (well, we did, really...).

>
> 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.

> The motivation behind this proposal is to make it easier for people to
> use different builds without having to learn to use the profile
> manager or pass command line flags, not to discourage people from
> using profiles across channels.

> 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

On 2013-07-22, at 15:42 , Gavin Sharp <ga...@gavinsharp.com> wrote:

> On Mon, Jul 22, 2013 at 6:56 AM, Johnathan Nightingale
> <joh...@mozilla.com> wrote:
>> Yep - there's a lot of good thinking in here about developer needs and
>> wants, but the proposed solution of another channel that is
>> close-to-but-not-exactly Nightly is a non-starter.
>
> "Another channel" is probably too narrow of a definition for the
> proposal (and probably implies too much around user
> exposure/marketing/etc.), but I do think that addressing the
> "developer side-by-side testing" use cases without harming bsmedberg's
> "temporary fix testing" and "channel switch with profile preservation"
> use cases might require a "close-to-but-not-exactly Nightly" approach.
>
> That could mean e.g. having separate "editions" of Aurora/Nightly/Beta
> that use a separate profile by default. Obviously that entrains a
> communication/user confusion problem (how do people distinguish
> between the two, etc.), but that problem might be better than our
> current problem (side-by-side testing is difficult), and hopefully
> there are ways we can mitigate it?

On 7/22/2013 12:42 PM, Gavin Sharp wrote:
> On Mon, Jul 22, 2013 at 6:56 AM, Johnathan Nightingale
> <joh...@mozilla.com> wrote:
>> Yep - there's a lot of good thinking in here about developer needs and
>> wants, but the proposed solution of another channel that is
>> close-to-but-not-exactly Nightly is a non-starter.
> "Another channel" is probably too narrow of a definition for the
> proposal (and probably implies too much around user
> exposure/marketing/etc.), but I do think that addressing the
> "developer side-by-side testing" use cases without harming bsmedberg's
> "temporary fix testing" and "channel switch with profile preservation"
> use cases might require a "close-to-but-not-exactly Nightly" approach.
>
> That could mean e.g. having separate "editions" of Aurora/Nightly/Beta
> that use a separate profile by default. Obviously that entrains a
> communication/user confusion problem (how do people distinguish
> between the two, etc.), but that problem might be better than our
> current problem (side-by-side testing is difficult), and hopefully
> there are ways we can mitigate it?

On Mon, Jul 22, 2013 at 12:47 PM, Rob Campbell <rcam...@mozilla.com> wrote:
> Would adding a menu option (could be in the Appmenu or Web Developer submenu) to restart the browser with Profile Manager to Aurora and Nightly help us for the cases where we need to run with a known profile?

On 2013-07-22, at 16:10 , Gavin Sharp <ga...@gavinsharp.com> wrote:

> On Mon, Jul 22, 2013 at 12:47 PM, Rob Campbell <rcam...@mozilla.com> wrote:
>> Would adding a menu option (could be in the Appmenu or Web Developer submenu) to restart the browser with Profile Manager to Aurora and Nightly help us for the cases where we need to run with a known profile?
>
> Hrm, that trades friction for running side-by-side with (a slightly
> reduced different) friction for people with bsmedberg's use cases. I'm
> not sure that's the right trade-off. I also somewhat share bsmedberg's
> view that we shouldn't expose the Profile Manager more widely as-is,
> so I think any solutions in this area would involve improving that
> experience somehow.

On Mon, Jul 22, 2013 at 1:32 PM, Rob Campbell <rcam...@mozilla.com> wrote:

This is where I think we could use some data. Not sure what the relative number of people who want a developer version to run alongside another running instance are compared to the number of people who need to test the same profile on different versions.

How could we find out?

On 2013-07-22 5:13 PM, Gavin Sharp wrote:
> I think all of the mentioned use cases[1] are valid, certainly. There
> are non-negligible costs to breaking the currently-addressed use cases
> (A and B) in favor of addressing the other (C), and the wins gained
> from doing so are difficult to measure, so I think we need to focus
> our attention on solutions that address use case C without
> significantly harming use cases A and B.
>
> Gavin
>
> [1] A) temporary bug fix testing, B) permanent migration to another
> channel, C) developer side-by-side testing
>

On Mon, Jul 22, 2013 at 5:01 PM, Mark Hammond <skippy...@gmail.com> wrote:
> Or to put it another way, I simply don't understand the use-case this is
> solving if not for the "won't someone think of the profiles" position (but
> that's OK - I guess I'm simply not a part of the target)

On Mon, Jul 22, 2013 at 3:07 PM, Mike Connor <mco...@mozilla.com> wrote:
> They're all valid, indeed, but are they equally important?

> A) temporary bug fix testing, B) permanent migration to another channel, C) developer side-by-side testing

On 7/22/2013 5:23 PM, Gavin Sharp wrote:
> On Mon, Jul 22, 2013 at 5:01 PM, Mark Hammond <skippy...@gmail.com> wrote:
>> Or to put it another way, I simply don't understand the use-case this is
>> solving if not for the "won't someone think of the profiles" position (but
>> that's OK - I guess I'm simply not a part of the target)
> The use case is "I want to run builds from different channels side by
> side but don't want to have to deal with -no-remote or
> -ProfileManager", essentially. I think it's easy to underestimate how
> much of a barrier dealing with those can be.
>
> Gavin

On 23/07/2013 10:23 AM, Gavin Sharp wrote:
> On Mon, Jul 22, 2013 at 5:01 PM, Mark Hammond <skippy...@gmail.com> wrote:
>> Or to put it another way, I simply don't understand the use-case this is
>> solving if not for the "won't someone think of the profiles" position (but
>> that's OK - I guess I'm simply not a part of the target)
>
> The use case is "I want to run builds from different channels side by
> side but don't want to have to deal with -no-remote or
> -ProfileManager", essentially. I think it's easy to underestimate how
> much of a barrier dealing with those can be.

On 23/07/2013 12:01 PM, Mark Hammond wrote:

>> The use case is "I want to run builds from different channels side by
>> side but don't want to have to deal with -no-remote or
>> -ProfileManager", essentially. I think it's easy to underestimate how
>> much of a barrier dealing with those can be.
>
> Right - what I meant was that I don't understand why that use-case
> exists.  Why is it considered self-evident that a majority of developers

On 2013-07-22, at 21:07 , Asa Dotzler <a...@mozilla.com> wrote:

> On 7/22/2013 5:23 PM, Gavin Sharp wrote:
>> On Mon, Jul 22, 2013 at 5:01 PM, Mark Hammond <skippy...@gmail.com> wrote:
>>> Or to put it another way, I simply don't understand the use-case this is
>>> solving if not for the "won't someone think of the profiles" position (but
>>> that's OK - I guess I'm simply not a part of the target)
>> The use case is "I want to run builds from different channels side by
>> side but don't want to have to deal with -no-remote or
>> -ProfileManager", essentially. I think it's easy to underestimate how
>> much of a barrier dealing with those can be.
>>
>> Gavin
>
> Isn't this the "shared profile" feature we wanted for running Firefox in desktop and metro modes at the same time?  If we had a profile that could be shared between different running instances of Firefox, would that fully cover this use case?

On Mon, Jul 22, 2013 at 7:10 PM, Mark Hammond <skippy...@gmail.com> wrote:
> I (obviously) accept there are good reasons to
> run side-by-side, but I'm suggesting that people who find dealing with
> multiple profiles a barrier would be just as happy shutting down Fx and
> starting up Aurora in their default profile.

On 2013-07-22 8:25 PM, Gavin Sharp wrote:
> On Mon, Jul 22, 2013 at 3:07 PM, Mike Connor <mco...@mozilla.com> wrote:
>> They're all valid, indeed, but are they equally important?
> Also a hard question, and implicit in my statement earlier was that
> I'm not so sure about their relative importance.
>
> I think you're underestimating the impact having to use a command line
> flag would have on A, and/or the importance of that use case.

On 2013-07-23 7:47 AM, Rob Campbell wrote:
> On 2013-07-22, at 21:07 , Asa Dotzler <a...@mozilla.com> wrote:
>> Isn't this the "shared profile" feature we wanted for running Firefox
>> in desktop and metro modes at the same time? If we had a profile that
>> could be shared between different running instances of Firefox, would
>> that fully cover this use case?
> I think it could potentially, but unlike sharing the same profile between two of The Same versions of Firefox, this would be sharing a profile between different versions (e.g., beta + nightly). I think this could be more than the feature is/was designed to be/do.
>
> in short, I don't think I'd recommend that over having a completely separate profile.

On Tue, Jul 23, 2013 at 10:24 AM, Mike Connor <mco...@mozilla.com> wrote:
> I think it's more than I value C to such a high degree that I'm willing to
> take some hit on A to drive C further and faster.
>
> To be clear, I do think A is important, and I also think we can segment A
> into:
>
> A1) Bugs that need to use your actual profile data to be verified.
> A2) Bugs that affect web-facing features or do not require specific profile
> data to be reproduced.
>
> I think that across the project A2 is a much bigger set than A1, and profile
> sharing in the A2 case is an unnecessary risk to those users (we know that
> upgrade/downgrade is far from perfect, and we don't actually want to limit
> ourselves or invest heavily it making downgrading 100% reliable).

> That said, if we can agree that A and B are important, I think there's a
> path forward here that actually supports all of the cases:
>
> Profiles are separate between "release" and "development" channels.
>
> On first run of a dev build, if there is a release profile, we can offer up
> a simple flow that makes it easy to accomplish all of these things: