Firefox Developer channel

[Anton Kovalyov]

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
_______________________________________________
firefox-dev mailing list
firef...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev

[Brandon Benvie]

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.

I think this is a good idea. It solves the problem we have with
developers need their own profile, and it also gives more visibility to
the Developer Tools to the group they're useful to (developers).

[Gijs Kruitbosch]

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?

~ Gijs

[Fitzgerald, Nick]

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?

Sorry, I mean it would pull down from m-c about once a week.

[Fitzgerald, Nick]

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?

It would pull down from Nightly about once a week.

[Anton Kovalyov]

mozilla-central. Developer channel should have faster release cycle than Aurora.

Anton

[Marco Bonardo]

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.

If it would be just for internal development (FirefoxOS), you could even
just borrow a project branch and merge central once a week to it. IT can
enable Nightly builds on that branch, and I think also automatic updates
(like UX). That would not be a channel, it's just a branch, but I
suspect would satisfy your needs without create confusion among other
users (and the press) with another release channel.
Though this may not be well suited for Web developers. But I suspect
Aurora was the channel intended for Wed developers, it has almost latest
technology and it's stable enough...

-m

[Jared Wein]

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

This. Basically, doing a developer channel is the simplest short-term solution to this problem but will probably carry with it much bigger long term issues (what do we do when the build is bad? do we need to track patches for the developer branch? how do we keep MDN up to date?, etc).

I think we need to go back to figuring out a way for web developers to use Aurora or Nightly side-by-side with Firefox Release or Beta.

Cheers,
Jared

[Alex Keybl]

Let's find a programmatic solution rather than creating another channel please. Fragmentation should be avoided at all costs.

-Alex

[Anton Kovalyov]

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.

Anton

[Mark Hammond]

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.

This seems a little like the worst of all possible worlds. We want more
people to use Nightly and Aurora. We declare it's not safe to do so
with your "regular" profiles, so this is a pain-point for people. We
propose to fix this by creating an entire new channel - the entire point
of it existing is to make it simpler to use with "throw away" profiles.
Still, we leave Nightly and Aurora "unsafe" to run with regular profiles.

It still seems the solution to me is to take steps that make it safe to
use your regular profile with Nightly and Aurora. All problems
described - along with a few not described here - are solved. Is this
problem really so intractable that we need such elaborate work-arounds
but still must tell everyone who will listen to never trust Aurora and
Nightly with a valuable profile?

Mark

[Mark Hammond]

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:

q) what's the difference between Nightly and Firefox Developer?
a) oh, they are exactly the same, except Firefox Developer will not use
your regular profile.
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!
q) err - ok - so what's the difference between Nightly and Firefox
Developer, apart from the fact Nightly defaults to something you
describe as insane and that I should never do?
a) Nothing!
q) err - ok - so what about Aurora?
a) Aurora is only available in the version that defaults to something
that we think is insane and you should never do.
q) errr - ok - but I'm a little speechless.
a) that wasn't a question!


Mark

[Anton Kovalyov]

On Jul 19, 2013, at 6:54 PM, Mark Hammond <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.

All we're trying to do is increase early feedback we get from web and Firefox OS developers about our tools. And increase is a strong word because right now we don't get any. Today people choose to run Stable/Beta because Aurora and Nightly are too unstable for them and they don't want to (don't know how to) manage multiple profiles. This means we don't get any feedback about our tools for at least a couple of months after we ship new features and bug fixes.

Anton 

[Mark Hammond]

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.

Cheers,

[Rob Campbell]

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.

I think the whole point and extent of this exercise is to allow people to use the latest nightly with a different profile for development use alongside their daily use profile.

For whatever it's worth, many of us use Nightly with our regular profiles with no real issues or data loss. The danger is pretty much a theoretical risk, but one we don't want to inflict on developers just the same.

~ r

[Mark Hammond]

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.

But this is my point entirely:

* We don't want to inflict a theoretical risk on developers.
* Thus, we use multiple profiles as a work-around and encourage
developers to use that.
* Thus, these developers never use nightly with their regular profile,
even though they would actually be happy to do so, all things being equal.
* Thus, these developers use nightly only very rarely, as it's
inconvenient to without their regular profile (no addons, no awesome
bar, no form history, etc).
* Thus, everyone loses, especially us, who has lost someone who might
have been happy to use nightly far more than they actually do.

I honestly don't share the belief that Chrome made the correct call
here. But I think I've probably worn out my welcome on this thread, and
you guys are all awesome - I'm sure you'll do something great anyway :)

Mark

[Gijs Kruitbosch]

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
>

So, reading everything, I think this is tempting but not the right thing
to do:

1) There'd basically be no reason for Aurora anymore. This is bad
because in fact this is exactly where we'd really like to have more
testing, AIUI. Our devs will scream if we break nightly (badly enough),
our users will only scream at beta. Sometimes, that's (too) late.

2) Bad PR for Aurora/Nightly.

3) Unhelpful in testing - if something regresses, you've got ~1 week
windows. At the current rate of m-c, that's a couple of hundred (perhaps
near 1000 these days?) csets. That's too much. Then you ask them to
bisect this week on Nightly... and we're back where we started.

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.

~ Gijs

[Marco Bonardo]

On 20/07/2013 06:34, Anton Kovalyov wrote:

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 think this is totally wrong. People who want stable Firefox should stay far away from Nightly, Aurora is for them. Unless by stable you mean that they don't have to update it every day.
Otherwise, what would make Developer Build stable? just merging central once a week won't make it more stable than Nightly, you may well hit a bad regression in your merge and have a totally unstable build. Are you going to test each changeset to get the more stable one in the week?

Regarding latest technology, I'm not sure why 6 weeks makes so much of a difference, was not a point of rapid release process to give new technology faster in Web developers hands? Why is Aurora so bad?

-m

[Mike de Boer]

The following describes my workflow, which I'd like to throw in for consideration.

1) Consider a new peecee. I download firefox release and install it. (the kind of default first thing you do when you get a new computer ;) )
2) Start up firefox and download the Nightly with it. Install the Nightly.
3) Start up Nighty with the command line flag -ProfileManager and UNtick the box 'Don't ask at startup'
4) Create a new profile 'dev', 'nightly', etc. next to 'default'.

Now each time I start any version of Fx I get to choose my profile. The instance I use for casual browsing, research, etc. I do not shutdown for days on end, so I don't care about the dialog I see once every few days. I don't have the time to let it annoy me. I don't care about startup speed, because I rarely (re)start the thing anyway.

Wins:
1) `./mach run` now asks me to choose a profile every time, so I can develop with add-ons, prefs, pink LightWeight Themes all I want without tampering with my default profile.
2) I can download/ run builds from any branch and create a different profile for 'em if I'm scared. Being the macho-man I am, I start them all with my default profile, to provoke the Gods. No, that's a lie.

I get that this just works for me personally. Others prefer to pass the profile to use on the command line directly, but I usually don't start my browser from the command line. Others care a lot about startup snappy-ness. Others want to show off the pink theme they're using.

Cheers,

Mike.

[Mike Ratcliffe]

A big part of this problem is the controlling of profiles via the
command line.

Would it not make sense to simply add a switch/create profile option to
the file menu and the first time a user runs nightly just ask them if
they would like to create a new profile? There could also be a checkbox
offering to use that profile by default for that channel.

This approach also has the advantage that profiles suddenly become
discoverable by Joe user. Armed with this knowledge Joe could then e.g.
use one profile for himself and one for his wife.

/Mike

[Mike Connor]

We've historically avoided exposing multi-profile support for the simple reason that the experience generally sucks for non-technical users, and we haven't prioritized fixing it. What you're suggesting is a really big hammer (and potential source of confusion) for our entire userbase, to solve a problem for a relative handful (let's call it a few hundred thousand users). It's the simple answer, but not necessarily the right one.

I do agree that better multi-profile support would make a lot of this easier, and were it on the roadmap I think we wouldn't necessarily go in this direction. That said, my understanding is that it's not currently a priority for desktop Firefox.

-- Mike

[Mike Connor]

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:

In general, I agree with everything Gijs wrote here. I'll also reinforce that Alex Keybl, who I would say has the best understanding of the effectiveness of our various channels, explicitly asked that we avoid further fragmentation. Given all of that, I think the original proposal is going to cause more problems than it will solve.

That said, I completely agree with the basic premise that we want to make it easier for developers to run development builds for testing and feedback. Part of the original premise behind the channels was that Aurora is the ideal channel for many of those developers, in that it is a generally stable channel with code that's 6-12 weeks out from release. That's when we want them catching bugs and reporting them to us. We should make the experience of using our developer channels as easy and seamless as possible.

To that end, I think we need to support the following use cases for Nightly/Aurora and Beta/Release:

1) Side by side usage

Having to quit your current session to run a different version is a pretty big roadblock. Any effective model needs to make this not just simple, but seamless. To me, seamless means that if Aurora is my default, links open there, not in whatever version of Firefox is running. don't believe the UX of -no-remote is right here, the experience on Android is much cleaner and more correct for me. This sort of works on OS X, but not at all well on Windows.

We know many developers (including many of us) will run multiple browsers side by side when testing. I think Aurora should be "just another browser" for those developers. Or, conversely, release could be that "other" browser they can fire up and test, if they're willing to dogfood full time.

2) Ability to share data between instances.

If we accept 1) above, we still need to allow our users to have consistent experiences (if they want that, if it's a testing/development environment they may not need or want all of their add-ons). I believe that Sync/PICL is an acceptable way for those users/developers to share data between instances/profiles, which would also mean we wouldn't force profiles through the churn of upgrade/downgrade cycles every time a user switches versions. Even if it's 100% reliable (and it hasn't been for me, especially when we were making a lot of session restore changes), it's still far from zero cost to migrate formats back and forth, so for me an ideal case would avoid that.

What this would mean:

* Developers can easily run both development and release builds in a way that minimizes their switching cost.
* Developers can choose explicitly which version is their primary version, and things will Just Work.
* Developers can choose to share data between versions if they want, or keep their non-default version clean

I think this would make Aurora much more appealing to developers and other testers. We've got the (partial) ability to migrate Firefox -> Firefox already, so we can craft a compelling first run if we want, and Sync already fills in some of the gaps that would be left (and this would be a great driver for PICL dogfooding when it's ready).

Anton, Gijs, is this a reasonable middle ground? Alex, do you think this would help or hurt the channel model in general?

-- Mike

[Johnathan Nightingale]

On Jul 19, 2013, at 5:45 PM, Alex Keybl wrote:

Let's find a programmatic solution rather than creating another channel please. Fragmentation should be avoided at all costs.

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.

Re-branding Nightly/Aurora to be more about the developers/experts that use it, and even giving it a couple of developer-specific behaviours (ability to run side-by-side without command line screwiness, defaulting to a separate profile, profile manager at launch, more developer-y default prefs), is very much worth discussing (I see mconnor distilling some of that out downthread). We'll need to be careful that we don't change things so much that we invalidate the testing coverage those channels offer but something like separate profiles seems pretty safe there.

Thanks for starting the thread, Anton.

J

---

Johnathan Nightingale

VP Firefox Engineering

@johnath

[Benjamin Smedberg]

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!

I don't understand what this is about. Why is this insane? This is what
we recommend, I hope!

--BDS

[Benjamin Smedberg]

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

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.

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.

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

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:

A:

* A user is using release and reports a bug having to do with some kind
of profile data (extensions installed, bookmarks, settings, whatever)
* We believe we've fixed it and the fix is available in
Nightly/Aurora/whatever
* We ask them to download the build with the fix and run it with their
existing profile to check

B:

* A user is using a release build. They want to help Mozilla and we ask
them to use Beta instead as their primary browser.
* The users bookmarks, extensions, and settings should be available
without any special action.

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.

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.

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.

--BDS

[Brian Bondy]

I provided a high level summary of the forked proposal in Bug 895030 here:
https://bugzilla.mozilla.org/show_bug.cgi?id=895030#c39

--
Thanks,
Brian R. Bondy

[Gavin Sharp]

On Fri, Jul 19, 2013 at 10:02 PM, Mark Hammond <skippy....@gmail.com> wrote:
> 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.

For the set of people already comfortable running Nightly (or Aurora
or Beta), I think doing so with their existing profiles is "fine" -
new profile vs. existing profile does not represent a significant
enough difference in risk to be worth worrying about, IMO.

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.

Gavin

[Rob Campbell]

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

[…]

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

… easier for people to use different builds _at the same time_.

I think that's the key thing to remember for this discussion.

~ rob

[Gavin Sharp]

On Fri, Jul 19, 2013 at 11:09 PM, Gijs Kruitbosch
<gijskru...@gmail.com> wrote:
> 1) There'd basically be no reason for Aurora anymore. This is bad because in

> 2) Bad PR for Aurora/Nightly.

I think here are a lot of assumptions being made about how we would
promote/expose the proposed new channel, how it is implemented etc.,
which is probably making this discussion more difficult (Anton's
proposal included some straw-man implementation details, but I think
we shouldn't focus on that too much).

The underlying problem is that we have separate audiences with
separate use cases, so finding a solution that addresses both at the
same time might be difficult. That's why I think a separate "channel"
could make sense (the implementation details behind that obviously
need to be discussed further).

> 3) Unhelpful in testing - if something regresses, you've got ~1 week
> windows. At the current rate of m-c, that's a couple of hundred (perhaps
> near 1000 these days?) csets. That's too much. Then you ask them to bisect
> this week on Nightly... and we're back where we started.

More people filing bugs with 1-week regression ranges can still be a
net win compared to fewer people filing bugs with narrower regression
ranges. Getting regression ranges for filed bugs and getting bugs
filed to begin with are somewhat orthogonal problems. People finding
regression ranges and people reporting bugs need not always be the
same.

That being said, figuring out the right update frequency for something
like this merits thought, I don't think anyone is particularly tied to
the specifics at this point.

> 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

This negatively impacts bsmedberg's use cases, which isn't ideal.

Gavin

[Gavin Sharp]

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?

Gavin

[Rob Campbell]

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?

I'm still pretty loathe to introduce an entirely separate channel.

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?

By default, Aurora and Nightly (maybe Beta) could start up with a different, special profile. In cases where you need to go back to your daily profile, restart with profile manager could be used.

This would get the Profile Manager out of the way by default, remove the need for a separate command line interaction that people don't like and remove the necessity for a separate release channel (which we don't like).

~ rob

[Robert Strong]

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?

Just putting this out there... awhile ago there was a discussion about
providing a xulrunner app for web developers that included all 4
channels that when launched would provide UI for selecting which channel
to use, could always launch with --no-remote, etc., would automatically
use a profile specific for the channel, and would include extensions for
web developers. The intent was to simplify testing pages with Firefox
for web developers.

Robert

[Gavin Sharp]

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.

Gavin

[Gavin Sharp]

This is a very interesting idea. We could promote such a tool
separately to Web Developers, without having to make any changes to
our builds/channels/etc. It would be interesting for someone in the
devtools team to prototype such a tool :)

(I suspect we might run into some issues with -no-remote
behavior/system integration/etc. that mconnor alluded to, but maybe
those are manageable.)

Gavin

[Rob Campbell]

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.

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?

~ rob

[Matthew N.]

That's very similar to what install-all-firefox[1] (from Anton's initial post) does but it only works on OS X and has a CLI interface. Since it's only mentioned quickly in the README, I'll point out that it optionally installs Firebug.

[1] https://github.com/omgmog/install-all-firefox

[Gavin Sharp]

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?

This seems like a difficult data-gathering exercise (measuring demand for something that doesn't yet exist, estimating relative sizes of populations, etc.), so while I certainly welcome ideas for measurement, I think we may need to reach decisions on what to do to address this without comprehensive data.

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

[Mike Connor]

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
>

They're all valid, indeed, but are they equally important? Which are
most important, and would have the greatest benefit to Firefox as a
whole? I would argue C, especially with explicit support for B. We
know we want far more developers testing on Aurora in particular, since
that gives them a stable enough experience that reporting bugs is high
value, and gives us lots of time to fix in advance of release. Making
it easier and better to run Aurora as a secondary browser would be a
pretty significant win for that user population. I think B is something
that we could also solve well by leveraging the existing Firefox ->
Firefox profile migration we use for reset. (We could do this without
exposing the current profile manager UI, happily.)

As for A, I'm not sure that's the dominant case that we should optimize
for, though I agree it's very difficult to produce anything loosely
resembling data. For the relative handful of times this is relevant I
think a command-line switch would be a completely acceptable way to
support this use-case, and would allow us to have a much better
experience if we did it right. We could have something like
|firefox.exe --test-with-profile=Release| which duplicates the user's
release profile for temporary testing, and deletes the copy on
shutdown. This would avoid all of the upgrade/downgrade corner cases we
know about, and is simple enough that any user capable of using Bugzilla
and installing side by side versions would be able to accomplish without
a headache.

-- Mike

[Bram Pitoyo]

Is there a merit in running this idea quickly (in a very lightweight
minisurvey) through our developer userbase and see what they think? We
need to phrase it in a balanced way so as not to favor side-by-side
vs. one-by-one, but then we can see results and interests (or lack
thereof).

[Mark Hammond]

On 23/07/2013 1:36 AM, Benjamin Smedberg wrote:
> 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!

> I don't understand what this is about. Why is this insane? This is what
> we recommend, I hope!

That's what I do too :) But at least a couple of references exist in
this thread to people wanting a new profile as they don't trust their
"real" profile with Nightly (IIRC, I got "insane" from

I get the impression this concern about "profile safety" underlies alot
of the angst around this. If I trusted Nightly with my main profile, I
don't understand why I'd bother making a new clean profile just to check
out some feature of Nightly or just to check my website still worked
with it (it'd take <10 seconds to swap channels for most of the target
audience).

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)

Mark

[Gavin Sharp]

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

[Gavin Sharp]

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.

Some better alternative ways to address B) would be welcome, but I
think we're going to always need to support the use case of "download
Beta build manually while running release", given that people
most-often discover these builds on the Web, so I'm skeptical that any
such improvements would make B unimportant.

That's why I think the most viable solutions involve addressing C
without having (too much) impact on A or B.

Gavin

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

[Asa Dotzler]

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?

- A

[Mark Hammond]

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.

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
want to run 2 channels side-by-side, rather than just loading their
entire profile/session in whatever channel they choose to use for a
specific task?

Mark

[John Bird]

Rather than share profiles:

I am in the " in boots and all" camp - that is I use Nightly for testing and
all my regular browsing. My 2 cents worth:

There is already options to backup/restore bookmarks, and the session store
I have found keeps several more or less "restore points" sessionstore-1.js
etc -or it used to and maybe doesn't add new ones any more.

I am perfectly happy to use Nightly, with all the attendant risks of a bad
version - which is about 8 years has never really happened - things have
always come right in a day or two.

To make more people happy to run nightly as their main session - you could
add:

1 - way to backup my bookmarks (already present)

2 - backup sessions- open tabs and tabgroups (not really present?)

3 - Backup settings (eg personalised settings in about:config)

4 - or an option to backup all the above in one go

so that if the profile turned to custard I could manually revive the stuff I
care about.

John Bird

[Mark Hammond]

Just to clarify:

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

... that a majority of developers *who find dealing with -no-remote or
-ProfileManager a barrier*. 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.

[Rob Campbell]

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?

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.

[Gavin Sharp]

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.

Developers don't like quitting their browsers, and if you're switching
back and forth between versions (e.g. developing in Aurora and testing
in Firefox), having to quit and restart between each iteration is
obviously annoying. They're different "apps" conceptually, that you
can't run them at the same time without jumping through hoops can be
an annoying limitation. (Part of this expectation also stems from the
fact that this is how Chrome Canary works.)

I don't think there's as much overlap between the sets of "people who
want to run side by side" and "people willing/able to deal with
profiles/profile manager" as you think there is :)

Gavin

[Mike Connor]

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.

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). In the A1 case I'd still argue that one-off testing should
also be zero-risk to user data, and copy-pasting a command-line argument
seems like a small price to pay in exchange for data safety for our
testers. The failure state here is that we mangle their profile data
somehow, even if it's just forked and confusing they're still going to
be negatively impacted by helping us, and I think that nets negative
over slightly easier ergonomics.

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:

========================
Welcome to Aurora! To make testing easier and more convenient, Firefox
and Aurora use different profiles. Tell us what you'd like to do!

A) I'm testing a bug! Please make a temporary copy of my profile, and
delete it when I quit Aurora.

B) I'm switching to Aurora permanently! Please migrate my profile data
to Aurora!

C) I'm going to run both Firefox and Aurora at the same time!
[x] Share data between my Firefox and Aurora profiles [1]
=======================

This avoids the current profile manager flow/command line options, and
supports all three use cases.

-- Mike

[1] This would leverage Sync/PICL. If the user has that set up, we'll
just configure that profile. If they don't, we can twiddle bits locally
given email + password.

[Mike Connor]

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.

IIRC, this was something we wanted to do on Android, and we eventually
forked it into separate profiles as the costs were simply far too high
to support the testing use-case. We've talked about a "profile data
service" on desktop a few times before, and we generally always conclude
that the costs are well in excess of what makes sense, especially as a
cross-platform product.

tl;dr Yes, but no.

-- Mike

[Gavin Sharp]

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

Fair enough - this is a convincing argument.

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

I agree that this seems like a nice end state. It will require a lot
of work to get right - how do we get there incrementally?

Gavin