Removal of the Profile Manager UI?

classic Classic list List threaded Threaded
124 messages Options
1234 ... 7
Reply | Threaded
Open this post in threaded view
|

Removal of the Profile Manager UI?

Henrik Skupin-2
While checking bug mail today I have seen a comment from Benjamin
Smedberg on bug 278860
(https://bugzilla.mozilla.org/show_bug.cgi?id=278860) which is about the
confusing profile manager warning when a profile is already in use. I
was really upset when reading his statement in comment 91:

> In any case, I'm
> trying to remove the profile manager in bug 214675, so I think this problem
> will be mostly moot.

>From bug 214675:

> I want to do this for the 1.9.3 cycle. This removes a fair bit of complexity
> from nsAppRunner.cpp and related code. This will help make it possible to
> refactor all our startup code (XPCOM and toolkit) into a single place. It will
> also make it possible to re-add a well-designed profile system like dmills
> wants to do for Weave integration that doesn't require application restart.

Why do we want to remove the Profile Manager UI? It sounds insane, even
with the knowledge that we do not have any alternative in place. So I
have to ask: why is it useless? What about our user base? Do we know
that much about everyone that we can make such an assumption? I don't
think so. Instead having a private discussion on a bug we should talk
about that issue in the public.

Given my QA point of view I would have to say that:

The profile manager is a component of Firefox we use heavily for
testing. Most of us have a profile for each of our branches. Further
other profiles exist for release testing and simply the daily checks.
Given that existing profiles will be deleted and new ones created very
often. Without an UI handling multiple profiles across branches will be
a hassle because it would require us to have shortcuts for each and
every of those profiles multiplied with the amount of branches
installed. I do not think that everyone will handle profile data with
the file manager.

Given the amount of bugs we triage over time a high percentage of those
filed bugs we were able to solve after proposing ways like Safe Mode or
creating a fresh profile. Having no UI anymore for profile management
would make it harder for any user to handle their profiles.

Personally I have to use it a dozen of times per day while jumping
between Minefield, Namoroka, Shiretoko, Gran Paradiso, and official
releases. I believe that a huge amount of users seeing it the same way.

As already said above we shouldn't remove such a wide-spread feature
without having anything else in place. We even don't know anything about
the addressed profile system dmills wants to have and when it will be
available - if it will be available.

Please don't do this.

my2c,

--
Henrik Skupin
QA Execution Engineer
Mozilla Corporation
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Removal of the Profile Manager UI?

Joshua Cranmer-2
On 01/12/2010 05:09 PM, Henrik Skupin wrote:
> The profile manager is a component of Firefox we use heavily for
> testing. Most of us have a profile for each of our branches. Further
> other profiles exist for release testing and simply the daily checks.

If you just need one profile per browser executable, one way of doing
this is to change the profile folder via application.ini's Name field (I
know it's very hackish). It doesn't solve the other use cases, though.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Removal of the Profile Manager UI?

John J Barton
In reply to this post by Henrik Skupin-2
Henrik Skupin wrote:
>
> The profile manager is a component of Firefox we use heavily for
> testing.

The problem with the alternative commandline solution is that the
platform puts garbage characters in front of the profile name when it
creates the profile directory. That means that you can't create new
profile with -p foo, then go looking for "foo" in your directories.

jjb
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Removal of the Profile Manager UI?

Tony Chung-2
In reply to this post by Henrik Skupin-2
On 1/12/10 2:09 PM, Henrik Skupin wrote:

> While checking bug mail today I have seen a comment from Benjamin
> Smedberg on bug 278860
> (https://bugzilla.mozilla.org/show_bug.cgi?id=278860) which is about the
> confusing profile manager warning when a profile is already in use. I
> was really upset when reading his statement in comment 91:
>
>> In any case, I'm
>> trying to remove the profile manager in bug 214675, so I think this problem
>> will be mostly moot.
>
>> From bug 214675:
>
>> I want to do this for the 1.9.3 cycle. This removes a fair bit of complexity
>> from nsAppRunner.cpp and related code. This will help make it possible to
>> refactor all our startup code (XPCOM and toolkit) into a single place. It will
>> also make it possible to re-add a well-designed profile system like dmills
>> wants to do for Weave integration that doesn't require application restart.
>
> Why do we want to remove the Profile Manager UI? It sounds insane, even
> with the knowledge that we do not have any alternative in place. So I
> have to ask: why is it useless? What about our user base? Do we know
> that much about everyone that we can make such an assumption? I don't
> think so. Instead having a private discussion on a bug we should talk
> about that issue in the public.
>
> Given my QA point of view I would have to say that:
>
> The profile manager is a component of Firefox we use heavily for
> testing. Most of us have a profile for each of our branches. Further
> other profiles exist for release testing and simply the daily checks.
> Given that existing profiles will be deleted and new ones created very
> often. Without an UI handling multiple profiles across branches will be
> a hassle because it would require us to have shortcuts for each and
> every of those profiles multiplied with the amount of branches
> installed. I do not think that everyone will handle profile data with
> the file manager.
>
> Given the amount of bugs we triage over time a high percentage of those
> filed bugs we were able to solve after proposing ways like Safe Mode or
> creating a fresh profile. Having no UI anymore for profile management
> would make it harder for any user to handle their profiles.
>
> Personally I have to use it a dozen of times per day while jumping
> between Minefield, Namoroka, Shiretoko, Gran Paradiso, and official
> releases. I believe that a huge amount of users seeing it the same way.
>
> As already said above we shouldn't remove such a wide-spread feature
> without having anything else in place. We even don't know anything about
> the addressed profile system dmills wants to have and when it will be
> available - if it will be available.
>
> Please don't do this.
>
> my2c,
>

QA spends quite a bit of time using the profile manager, and often even
multiple profiles on the same build (-no-remote), to search and
reproduce scenarios.  Joshua, can your hack idea with application.ini
work around this use case?

I think Henrik's point here is worth discussing as many of us from
Mozilla QA have come to depend heavily on profile switching using this
interface.   I'm only speaking for Firefox, but i'm sure there are many
other mozilla products that use Profile Manager and would love to chime
in.   Manual and automated testcases have been written with this
component in mind, and that would mean having to adjust all of them if
this went away.  A new tool would need to be created in place, which
means additional resources would be asked to step in to retain our
current work environment with this component.   While i understand the
decision isnt' final of this archaic tool, and still a discussion within
bug 214675, i'd like to know if there's a better place and time to lay
out a justification and decision on why we really want to remove it.

crossposting to mozilla.dev.platform

Tony
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Removal of the Profile Manager UI?

Dave Townsend
In reply to this post by John J Barton
On 1/12/10 15:29, John J Barton wrote:
> Henrik Skupin wrote:
>>
>> The profile manager is a component of Firefox we use heavily for
>> testing.
>
> The problem with the alternative commandline solution is that the
> platform puts garbage characters in front of the profile name when it
> creates the profile directory. That means that you can't create new
> profile with -p foo, then go looking for "foo" in your directories.

Actually it is the profile UI that adds the garbage characters. Doing
everything from the command line does not.

With the patch as suggested you will still be able to just run
"firefox.exe -profile mydir" to point it to a directory to use for the
profile.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Removal of the Profile Manager UI?

Zack Weinberg-6
In reply to this post by Joshua Cranmer-2
Joshua Cranmer <[hidden email]> wrote:

> On 01/12/2010 05:09 PM, Henrik Skupin wrote:
> > The profile manager is a component of Firefox we use heavily for
> > testing. Most of us have a profile for each of our branches. Further
> > other profiles exist for release testing and simply the daily
> > checks.
>
> If you just need one profile per browser executable, one way of doing
> this is to change the profile folder via application.ini's Name field
> (I know it's very hackish). It doesn't solve the other use cases,
> though.

I have a patch permanently at the bottom of my mq stack that does
exactly this (among other things) so that I can have confidence that my
development builds are never, ever exposed to any random crap that may
be in my regular profile(s).

I would be most pleased if something like that became a ./configure
option, although I don't imagine it would cover everything that the
patch does.  Normal people don't want the system extension directories
forcibly disabled at compile time, for instance :-)

zw
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Removal of the Profile Manager UI?

Mike Beltzner
In reply to this post by Henrik Skupin-2
FWIW, I actually think that we should be discussing this in dev.platform, not dev.planning, but here we are.

On 2010-01-12, at 5:09 PM, Henrik Skupin wrote:

>> I want to do this for the 1.9.3 cycle. This removes a fair bit of complexity
>> from nsAppRunner.cpp and related code. This will help make it possible to
>> refactor all our startup code (XPCOM and toolkit) into a single place. It will
>> also make it possible to re-add a well-designed profile system like dmills
>> wants to do for Weave integration that doesn't require application restart.

These sound like virtuous reasons. I should also note that the profile manager UI, as it exists, is literally the lowest potential bar and was meant to be removed from Firefox (see that bug's history) before v1.0 shipped.

Now, I'm a user of the Profile Manager, as are, I suspect, many Firefox developers. However, I recognize that we, as an aggregate group, represent not even a tenth of a percentage of our total user base. While I don't think anyone's arguing that we should retain the current system solely on the basis that it's very helpful for testers and developers, I do think that before this change is committed to the codebase, we should determine who will be affected and clearly communicate alternative pathways.

We may even wish to build a little application harness that replicates the function of the existing UI - that shouldn't be too hard to do, if I understand things correctly.

> Why do we want to remove the Profile Manager UI? It sounds insane, even
> with the knowledge that we do not have any alternative in place. So I
> have to ask: why is it useless? What about our user base? Do we know
> that much about everyone that we can make such an assumption? I don't
> think so. Instead having a private discussion on a bug we should talk
> about that issue in the public.

Nobody has said it is useless, but it's clearly not a great tool that's suffered from underinvestment. If it's not very useful, and not used at all by the majority of our users (despite your question, I think we can assume that the vast majority of our users do not use a command-line-option required tool). It's lacking functionality that would be truly useful such as duplicating profiles, copying profiles, creating one-time-use profiles, and hasn't had any serious investment since it was created.

At the same time, there's a real cost in terms of our ability to modify the startup code pathways which may yield significant improvements in startup time. Taras has indicated that by removing the profile manager we will see an immediate and perceptible improvement in Ts, one of the metrics on which we compete.

> Given my QA point of view I would have to say that:

I've excised most of your original points here, and will instead summarize a set of requirements:

 - the ability to manage a large set of profiles
 - the ability to choose a profile and branch of Firefox to launch
 - the ability for end users to reset their profile or create a new one

To that I'll add a bunch more requirements that I think would be even MORE useful for you:

 - the ability to clone or duplicate a profile
 - the ability to create a one-time-use profile
 - the ability to generate a profile with certain default preferences or in a snapshot state
 - the ability to back up an entire profile
 - the ability to package a profile for migration to a new system
 - the ability to unpack a profile that's being migrated from an existing system

I think that most of these requirements can be bundled into an ancillary tool that are QA and tester focused and distributed separately (call it Firefox Starter's Gun), and some should be turned into tools that are available within the product for users (either as part of Safe Mode, or the main UI)

We can make these changes precursors to the actual removal of the code, or start projects so that the time that it will affect you and other testers on trunk will be short, at least.

cheers,
mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Removal of the Profile Manager UI?

Cheng Wang-2
In reply to this post by Tony Chung-2
Tony Chung wrote:

> On 1/12/10 2:09 PM, Henrik Skupin wrote:
>> While checking bug mail today I have seen a comment from Benjamin
>> Smedberg on bug 278860
>> (https://bugzilla.mozilla.org/show_bug.cgi?id=278860) which is about the
>> confusing profile manager warning when a profile is already in use. I
>> was really upset when reading his statement in comment 91:
>>
>>> In any case, I'm
>>> trying to remove the profile manager in bug 214675, so I think this
>>> problem
>>> will be mostly moot.
>>[cut]

Even setting aside internal uses, making a new profile via the profile
manager is a KEY troubleshooting step in support since it gives us a
clean profile.  Sorry to say but sometimes a user's profile is so broken
that we just have to nuke everything, make a new profile and then
recover the data we can (doubly so when Weave could potentially upstream
missing data and thus propagating a localized disaster into a
nightmare).  It's also the only solution for users who want to run
multiple instances of Firefox for different users/usecases without
forcing a logout/login cycle.  Lastly, there are tips sites all over the
web that suggest multiple profiles for various tasks (I know Lifehacker
does for example).  I think we should find out if it's more popular than
we think before we remove it.  IF we were to do this (I'm not saying I
like the current UI), I'd like to have: 1) some sort of better safe
mode/data recovery mode that gives you clean places.sqlite etc.  2) Some
alternative to have different users on the same Firefox install (Weave
may be doing this) 3) Good, clear steps to help users who are currently
running multiple profiles keep this functionality.  (Maybe a tool that
lets you make a shortcut for your other profiles on your desktop/in your
start menu).

I'm not saying I like the current UI and that it's without its problems,
I'm just saying it has specific and very important uses for our users
(and not just us).  Until we can replace these usecases with better
alternatives, let's keep what we have.

If you need me to justify with concrete numbers I can find out how many
times in a given week on LiveChat we help a user by using the profile
manager compared to how many times we need to fix a problem caused by
it.  I suspect it's easily 5:1 or higher.

Cww.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Removal of the Profile Manager UI?

David E. Ross-3
In reply to this post by Joshua Cranmer-2
On 1/12/2010 2:38 PM, Joshua Cranmer wrote:
> On 01/12/2010 05:09 PM, Henrik Skupin wrote:
>> The profile manager is a component of Firefox we use heavily for
>> testing. Most of us have a profile for each of our branches. Further
>> other profiles exist for release testing and simply the daily checks.
>
> If you just need one profile per browser executable, one way of doing
> this is to change the profile folder via application.ini's Name field (I
> know it's very hackish). It doesn't solve the other use cases, though.

I'm a user, not a developer.  I have one instance of a browser
installed.  I have four profiles for that browser.  Three of those
profiles I use regularly; the fourth is for the use of guests who might
not appreciate how I've configured the other three.  Currently, I've
been thinking of creating additional profiles for frequent visitors, a
separate profile for each visitor.

Additionally, when I report a bug, your developers often ask me to
create a whole new (but temporary) profile to test that bug further.  If
I don't have a user interface to create and delete profiles, my
cooperation in that effort will cease.

Is bug #214675 for the benefit of end users or for the benefit of a few
developers?

--

David E. Ross
<http://www.rossde.com/>.

Don't ask "Why is there road rage?"  Instead, ask
"Why NOT Road Rage?" or "Why Is There No Such
Thing as Fast Enough?"
<http://www.rossde.com/roadrage.html>
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Removal of the Profile Manager UI?

Edward Hume
In reply to this post by Henrik Skupin-2
On Jan 12, 7:38 pm, Mike Beltzner <[hidden email]> wrote:

> I think that most of these requirements can be bundled into an ancillary tool that are QA and tester focused and distributed separately (call it Firefox Starter's Gun), and some should be turned into tools that are available within the product for users (either as part of Safe Mode, or the main UI)
>
> We can make these changes precursors to the actual removal of the code, or start projects so that the time that it will affect you and other testers on trunk will be short, at least.
>
> cheers,
> mike

Since Netscape I've always wanted the ability to go into the Files
dropdown menu and change profiles. As it is now, I have shortcuts that
specify which profiles they go to. So, for me as a themes developer, I
use the Profiles UI only if something gets bunged up and I have to fix
it.

That said, a tool that is available "within the product" would be
great. But like Mike, I wouldn't remove the old UI until a new tool
has been debugged and is in use. Repeat - in use. Then the old UI can
go.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Removal of the Profile Manager UI?

Mike Beltzner
On 1/12/2010 9:14 PM, Ed Hume wrote:
> That said, a tool that is available "within the product" would be
> great. But like Mike, I wouldn't remove the old UI until a new tool
> has been debugged and is in use. Repeat - in use. Then the old UI can
> go.

(sorry for the duplicate; cross-posting sucks for this precise reason)

That's been a misreading of what I said. I said that bugs should be
filed for the development of the new features and tools, and alternative
mechanisms of supporting the existing tasks should be documented, but
certainly on mozilla-central we shouldn't delay changes that are
required in order to move forward with our plans to improve startup time
or better integration with Weave.

We obviously won't ship a product to users that regresses important
functionality that our support teams rely on (as Cheng indicated), but I
think we can ship nightly and development builds without a profile
manager for a while as long as we correctly document how to achieve the
same functionality with command line arguments.

cheers,
mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Removal of the Profile Manager UI?

Benjamin Smedberg
In reply to this post by Henrik Skupin-2
On 1/12/10 5:09 PM, Henrik Skupin wrote:

> Given my QA point of view I would have to say that:
>
> The profile manager is a component of Firefox we use heavily for
> testing. Most of us have a profile for each of our branches. Further
> other profiles exist for release testing and simply the daily checks.
> Given that existing profiles will be deleted and new ones created very
> often. Without an UI handling multiple profiles across branches will be
> a hassle because it would require us to have shortcuts for each and
> every of those profiles multiplied with the amount of branches
> installed. I do not think that everyone will handle profile data with
> the file manager.

I'm not sure I understand your current workflow. You unpack/install/whatever
a version of Firefox, and then you open a command line and run firefox.exe
-P -no-remote to get to the profile manager? Or is it something less or more
complicated?

There seem to be two issues in response:

* user support tasks of backing up/cleaning a profile
* heavy-duty QA and other people who regularly use multiple profiles.

It seems to me that these two use cases present very different needs.

In terms of user support, it would be relatively easy and enjoyable to
modify the current "safe mode" to provide additional options such as "back
up my data" and "wipe all my data and start over fresh". I'm all for doing
this, since by itself it doesn't cause a lot of complexity in the startup
path. If these two options are insufficient, we should talk about what set
of options would be sufficient, with the provision that I'd like to avoid
exposing multiple profiles or the concept of profiles to end users as much
as possible. It's just "my Firefox data", and the fact that we store in in
with the label "default profile" is an implementation detail that can change
(and is).

I've been treating the QA/multi-profile case with much less interest,
primarily because if you're in that group, you are probably already
comfortable with a command prompt, and `firefox -profile dir` is just as
simple as `firefox -P`.

It's almost trivial to write a python script which presents a list of
profiles/directories and selects one before launching Firefox (passing the
directory in -profile), if that is somehow helpful. Would a python script
from the command line solve the QA case sufficiently?

> Personally I have to use it a dozen of times per day while jumping
> between Minefield, Namoroka, Shiretoko, Gran Paradiso, and official
> releases. I believe that a huge amount of users seeing it the same way.

Why? We don't recommend that most people, even beta users, use different
profiles for different releases: we *want* people to use the same profile as
much as possible, so that upgrade/downgrade problems across branches get as
much visibility as possible. I understand that QA may have different
requirements than ordinary beta users, but I don't think we should
extrapolate out to "a huge number of users". I think we've done a fairly
effective job of hiding the profile manager so that it never appears unless
you use the command line an explicitly ask for it.

> As already said above we shouldn't remove such a wide-spread feature
> without having anything else in place. We even don't know anything about
> the addressed profile system dmills wants to have and when it will be
> available - if it will be available.

Other than I heard dmills wanted to do something with Weave and making it
possible for multiple users to use the browser without conflicting, we
should presume that *nothing* is planned in that department, and this
removal is a standalone decision that was prompted by code complexity,
serious bugs, and maintenance costs in the current profile manager.

--BDS
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Removal of the Profile Manager UI?

Justin Wood (Callek)-2
In reply to this post by Henrik Skupin-2
Coming from the SeaMonkey side of things mostly, a lack of profile
manager will hurt. But this is not about just a SeaMonkey consumer, its
about all Gecko consumers, and have based my responses on the latter...

On 1/12/2010 7:38 PM, Mike Beltzner wrote:

> On 2010-01-12, at 5:09 PM, Henrik Skupin wrote:
>
>>> I want to do this for the 1.9.3 cycle. This removes a fair bit of complexity
>>> from nsAppRunner.cpp and related code. This will help make it possible to
>>> refactor all our startup code (XPCOM and toolkit) into a single place. It will
>>> also make it possible to re-add a well-designed profile system like dmills
>>> wants to do for Weave integration that doesn't require application restart.
>
> These sound like virtuous reasons. I should also note that the profile manager UI, as it exists, is literally the lowest potential bar and was meant to be removed from Firefox (see that bug's history) before v1.0 shipped.
>
> Now, I'm a user of the Profile Manager, as are, I suspect, many Firefox developers. However, I recognize that we, as an aggregate group, represent not even a tenth of a percentage of our total user base. While I don't think anyone's arguing that we should retain the current system solely on the basis that it's very helpful for testers and developers, I do think that before this change is committed to the codebase, we should determine who will be affected and clearly communicate alternative pathways.
>
> We may even wish to build a little application harness that replicates the function of the existing UI - that shouldn't be too hard to do, if I understand things correctly.

Building an application harness is ok, I'd love if XULRunner let you
"generate" said harness when installing XULRunner apps though. (for
those XULRunner apps that wish to make use of a profile manager)

>> Why do we want to remove the Profile Manager UI? It sounds insane, even
>> with the knowledge that we do not have any alternative in place. So I
>> have to ask: why is it useless? What about our user base? Do we know
>> that much about everyone that we can make such an assumption? I don't
>> think so. Instead having a private discussion on a bug we should talk
>> about that issue in the public.
>
> Nobody has said it is useless, but it's clearly not a great tool that's suffered from underinvestment. If it's not very useful, and not used at all by the majority of our users (despite your question, I think we can assume that the vast majority of our users do not use a command-line-option required tool). It's lacking functionality that would be truly useful such as duplicating profiles, copying profiles, creating one-time-use profiles, and hasn't had any serious investment since it was created.
>
> At the same time, there's a real cost in terms of our ability to modify the startup code pathways which may yield significant improvements in startup time. Taras has indicated that by removing the profile manager we will see an immediate and perceptible improvement in Ts, one of the metrics on which we compete.

I can understand the Ts Cost, but even if the UI is far from ideal and
not "used everyday by most users" at what point do we consider barrier
to entry with downloading a seperate "app pack" (given also potential
for users to be on LOCKED DOWN systems where they can't install an app
pack; or in situations where any file that is downloaded and executeable
can't be run, etc. that would prevent running FF profile manager
entirely for troubleshooting/QA issues).

>> Given my QA point of view I would have to say that:
>
> I've excised most of your original points here, and will instead summarize a set of requirements:
>
>   - the ability to manage a large set of profiles
>   - the ability to choose a profile and branch of Firefox to launch
>   - the ability for end users to reset their profile or create a new one

These are good as a "must have". and imo, without them the product is
BARELY qualifyable as dogfoodable as a dev.

> To that I'll add a bunch more requirements that I think would be even MORE useful for you:
>
>   - the ability to clone or duplicate a profile
>   - the ability to create a one-time-use profile
>   - the ability to generate a profile with certain default preferences or in a snapshot state
>   - the ability to back up an entire profile
>   - the ability to package a profile for migration to a new system
>   - the ability to unpack a profile that's being migrated from an existing system

These would be wonderful features and additions... but some of these
actions are probably app-dependant and would need app-specific potential
extensibility (TB, XULRunner apps, etc.) [for: backup, package... etc.]

> I think that most of these requirements can be bundled into an ancillary tool that are QA and tester focused and distributed separately (call it Firefox Starter's Gun), and some should be turned into tools that are available within the product for users (either as part of Safe Mode, or the main UI)
>
> We can make these changes precursors to the actual removal of the code, or start projects so that the time that it will affect you and other testers on trunk will be short, at least.

I would be happy to "make these changes precursors to the actual removal
of the code, ... on trunk". If we however simply "file bugs, remove the
code and wait... just simply blocking final release on a package "being
available" it will hurt too much to even consider any trunk development
or work for me, in the foreseeable future.

Two requirements I would like to make on the actual removal of this code:
-Patch[es] to make the first of those first three requirements as you
summarized possible, even if seperate app. with a configure option to
m-c that allows us to build said seperate app in a normal build (if not
built by default) and distribute with normal nightlies (RC's etc, are
another story imo).
-Have said patch ready within a week of the profile manager UI to ensure
trunk stays easily dogfoodable for the rest of us, with the promise of
either a m-c-wide freeze, or backout of profile-code-removal if not
ready. [I seem to remember a requirement of "days away from release" for
m-c going forward tossed around a lot].

-
~Justin Wood (Callek)
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Removal of the Profile Manager UI?

Chris Hofmann-3
In reply to this post by Benjamin Smedberg

On 1/12/10 7:22 PM, Benjamin Smedberg wrote:

> On 1/12/10 5:09 PM, Henrik Skupin wrote:
>
>> Given my QA point of view I would have to say that:
>>
>> The profile manager is a component of Firefox we use heavily for
>> testing. Most of us have a profile for each of our branches. Further
>> other profiles exist for release testing and simply the daily checks.
>> Given that existing profiles will be deleted and new ones created very
>> often. Without an UI handling multiple profiles across branches will be
>> a hassle because it would require us to have shortcuts for each and
>> every of those profiles multiplied with the amount of branches
>> installed. I do not think that everyone will handle profile data with
>> the file manager.
>
> I'm not sure I understand your current workflow. You
> unpack/install/whatever a version of Firefox, and then you open a
> command line and run firefox.exe -P -no-remote to get to the profile
> manager? Or is it something less or more complicated?
>
> There seem to be two issues in response:
>
> * user support tasks of backing up/cleaning a profile
> * heavy-duty QA and other people who regularly use multiple profiles.
>
I think its unlikely that users that share a computer will be showing up
in this newsgroup to advocate for a feature they use everyday.   If you
do a bit of hunting you find quite a few articles like this

http://lifehacker.com/231646/geek-to-live--manage-multiple-firefox-profiles
http://ahtim.com/create-multi-user-profiles-in-firefox/

google says there is something like 5700 more pages like this
http://www.google.com/search?hl=en&q=%22firefox+multiple+users%22&aq=f&oq=&aqi=

some solution for these kinds of use cases seems appropriate.

-chofmann

> It seems to me that these two use cases present very different needs.
>
> In terms of user support, it would be relatively easy and enjoyable to
> modify the current "safe mode" to provide additional options such as
> "back up my data" and "wipe all my data and start over fresh". I'm all
> for doing this, since by itself it doesn't cause a lot of complexity
> in the startup path. If these two options are insufficient, we should
> talk about what set of options would be sufficient, with the provision
> that I'd like to avoid exposing multiple profiles or the concept of
> profiles to end users as much as possible. It's just "my Firefox
> data", and the fact that we store in in with the label "default
> profile" is an implementation detail that can change (and is).
>
> I've been treating the QA/multi-profile case with much less interest,
> primarily because if you're in that group, you are probably already
> comfortable with a command prompt, and `firefox -profile dir` is just
> as simple as `firefox -P`.
>
> It's almost trivial to write a python script which presents a list of
> profiles/directories and selects one before launching Firefox (passing
> the directory in -profile), if that is somehow helpful. Would a python
> script from the command line solve the QA case sufficiently?
>
>> Personally I have to use it a dozen of times per day while jumping
>> between Minefield, Namoroka, Shiretoko, Gran Paradiso, and official
>> releases. I believe that a huge amount of users seeing it the same way.
>
> Why? We don't recommend that most people, even beta users, use
> different profiles for different releases: we *want* people to use the
> same profile as much as possible, so that upgrade/downgrade problems
> across branches get as much visibility as possible. I understand that
> QA may have different requirements than ordinary beta users, but I
> don't think we should extrapolate out to "a huge number of users". I
> think we've done a fairly effective job of hiding the profile manager
> so that it never appears unless you use the command line an explicitly
> ask for it.
>
>> As already said above we shouldn't remove such a wide-spread feature
>> without having anything else in place. We even don't know anything about
>> the addressed profile system dmills wants to have and when it will be
>> available - if it will be available.
>
> Other than I heard dmills wanted to do something with Weave and making
> it possible for multiple users to use the browser without conflicting,
> we should presume that *nothing* is planned in that department, and
> this removal is a standalone decision that was prompted by code
> complexity, serious bugs, and maintenance costs in the current profile
> manager.
>
> --BDS
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Removal of the Profile Manager UI?

Benjamin Smedberg
In reply to this post by Benjamin Smedberg
On 1/12/10 10:47 PM, chris hofmann wrote:

> I think its unlikely that users that share a computer will be showing up
> in this newsgroup to advocate for a feature they use everyday. If you do
> a bit of hunting you find quite a few articles like this
>
> http://lifehacker.com/231646/geek-to-live--manage-multiple-firefox-profiles
> http://ahtim.com/create-multi-user-profiles-in-firefox/
>
> google says there is something like 5700 more pages like this
> http://www.google.com/search?hl=en&q=%22firefox+multiple+users%22&aq=f&oq=&aqi=
>
>
> some solution for these kinds of use cases seems appropriate.

There are lots of things that might be good, if we had infinite amounts of
time. But we have repeatedly and consistently said, since Firefox 0.9 or so,
that GUI management of multiple profiles is not a use case that we actively
support, precisely because doing it right would require lots of work.

I believe in having UI so that SUMO can solve end-user problems effectively.
I believe in making sure QA can still function. I don't think that "5700
people want the profile manager the way netscape had it" is a good argument
for keeping this UI.

--BDS
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Removal of the Profile Manager UI?

Atsushi Shimono-2
In reply to this post by Mike Beltzner
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

  hi,

(2010/01/13 9:38), Mike Beltzner wrote:

>>> I want to do this for the 1.9.3 cycle. This removes a fair bit of complexity
>>> from nsAppRunner.cpp and related code. This will help make it possible to
>>> refactor all our startup code (XPCOM and toolkit) into a single place. It will
>>> also make it possible to re-add a well-designed profile system like dmills
>>> wants to do for Weave integration that doesn't require application restart.
>
> These sound like virtuous reasons. I should also note that the profile manager UI,
> as it exists, is literally the lowest potential bar and was meant to be removed
> from Firefox (see that bug's history) before v1.0 shipped.
>
> Now, I'm a user of the Profile Manager, as are, I suspect, many Firefox developers.
> However, I recognize that we, as an aggregate group, represent not even a tenth of
> a percentage of our total user base. While I don't think anyone's arguing that we
> should retain the current system solely on the basis that it's very helpful for
> testers and developers, I do think that before this change is committed to the
> codebase, we should determine who will be affected and clearly communicate alternative
> pathways.

  Not only for developers and QAs, for community user support some flow-charts
including some test with creating a completely new profile using profile manager.
  Mainly for extensions, but it IS really useful to distinguish what is the problem.
  This might be the flow only in Japan, I don't know for others, I want to say that
every existing scheme might be used in as-yet-unknown way for developers..
# like xul darkmatter? :-p


  Masayuki, developer in Mozilla Japan, once said that it might be ok with asking
'renaming' Firefox directory including profiles (mostly parent of the profiles),
but I think it is difficult for some low-skilled users to search its path. So, I'd
rather like to have some UI to manage them in Firefox itself or in its safe mode.


  just $.02
- --
Atsushi Shimono
 mail : shimono @ gmail.com / mixi id : 7708 / http://blog.himor.in/
 skype :  shimono_univ (w/cam) / http://facebook.com/himorin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)

iQIcBAEBCgAGBQJLTUrOAAoJEHI5evwJBSZd+d4QAKZSOeDzcNqBpI9nICewT/rf
PzY+aDwZGTQYkp9g0zU91k7TKqzi2gU9B8Nq9Rb9xOI4247++fLcMFiWZRqW9/tc
H3RzprhmOL2aGzHP37L6MdCltrmKZ9/F2JZ+9rg/xluCTQi5pNpqYowtWqGPLW1G
kIfuxMyT0WE7ctHzM/qq3IENmlPpBh9c7hyZ2FxjkoMwAGzTsYtbXtbzUAvV6HVx
e5lq9q4vxW92SvecKRLdN+84yNUECyyBJiSJU99Q0qAC6hj3GpUfBcHltowWAk9N
3LFjRZJrP3RQdBaE4D51Y8w1ohVQ2RrcGam22Y5vfRCGxK3DNWW6pmONrd32jtGd
U0i8GnOB0Y9b2A6Xn4S7enReWMiKBSHN8jb2fwyeH9k12DmKsxYV627KDRKvaIoQ
LL5PLkU6cfmem+Ue7HTTaCHW96ttPBogzXSMIPjimrUPFDAcUHKXahL21KmaypqB
hFbYEGxSV/GxJUdwsaHi82mUMSaxBWP6kbOVgijY91yoA/bYMItX0hvRwilEj0yn
oLLnjms614l/4tO2w3GZRxPpw/0mkbMBw46HNr25Huvlm/dCib4i45m2hI7eq5rs
i1/SpdR4gYVDfMhtzmJ4/KqOFsvTJ56CbQu6LsMK3DTwyo2d5jT7RO4b212y08u8
pAH++Yyb9T99YZ0I5W+N
=uVf4
-----END PGP SIGNATURE-----
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Removal of the Profile Manager UI?

L. David Baron
In reply to this post by Benjamin Smedberg
On Tuesday 2010-01-12 22:22 -0500, Benjamin Smedberg wrote:
> I've been treating the QA/multi-profile case with much less
> interest, primarily because if you're in that group, you are
> probably already comfortable with a command prompt, and `firefox
> -profile dir` is just as simple as `firefox -P`.

I think some people may not be fully aware of the -profile option,
so I want to point out two things explicitly (especially the second,
which I realized at least one person didn't know based on an
in-person conversation earlier today):

 * -profile <directory> lets you use an alternate profile in a
   manner similar to -P <profilename>, except that its argument is
   the location of the profile directory rather than the name of the
   profile within the standard profile directory location

 * Using -profile <directory> on an empty directory makes Firefox
   create a new profile in that directory.

-David

--
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Removal of the Profile Manager UI?

Benjamin Smedberg
In reply to this post by Benjamin Smedberg
On 1/12/10 11:32 PM, L. David Baron wrote:

>   * Using -profile<directory>  on an empty directory makes Firefox
>     create a new profile in that directory.

FWIW, this last bit is a new feature added to mozilla-central fairly
recently... I don't think it has made it to the stable branches.

--BDS

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Removal of the Profile Manager UI?

Mike Shaver
On Tue, Jan 12, 2010 at 11:49 PM, Benjamin Smedberg
<[hidden email]> wrote:
> On 1/12/10 11:32 PM, L. David Baron wrote:
>
>>  * Using -profile<directory>  on an empty directory makes Firefox
>>    create a new profile in that directory.
>
> FWIW, this last bit is a new feature added to mozilla-central fairly
> recently... I don't think it has made it to the stable branches.

Worked fine in 3.5, and I think before, you just had to create the
directory beforehand.  Do you mean that central creates if ENODIR now?

Mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Removal of the Profile Manager UI?

Axel Hecht-2
In reply to this post by Edward Hume
On 13.01.10 03:34, Mike Beltzner wrote:

> On 1/12/2010 9:14 PM, Ed Hume wrote:
>> That said, a tool that is available "within the product" would be
>> great. But like Mike, I wouldn't remove the old UI until a new tool
>> has been debugged and is in use. Repeat - in use. Then the old UI can
>> go.
>
> (sorry for the duplicate; cross-posting sucks for this precise reason)
>
> That's been a misreading of what I said. I said that bugs should be
> filed for the development of the new features and tools, and alternative
> mechanisms of supporting the existing tasks should be documented, but
> certainly on mozilla-central we shouldn't delay changes that are
> required in order to move forward with our plans to improve startup time
> or better integration with Weave.
>
> We obviously won't ship a product to users that regresses important
> functionality that our support teams rely on (as Cheng indicated), but I
> think we can ship nightly and development builds without a profile
> manager for a while as long as we correctly document how to achieve the
> same functionality with command line arguments.
>

Glancing at the patch, we'd still be reading profiles.ini. I kinda like
the idea of not having to remember salted profile directory names, or
having to cd to some special directory, could we keep the profile name
piece around on the command line (i.e. -P debug)? Sounds like that'd not
really have a major impact on the remaining code and its complexity. We
can postpone adding stuff to profiles.ini for an external tool (like vi,
for the meantime), I guess that most test infrastructure would work with
an explicit path anyway.

Nit, you probably didn't want to comment out SOURCE_STAMP in the patch,
Benjamin?

As a clarification, Benjamin, do you expect a TS win here? I don't know
how much of the removed code is migration, and whether Taras actually
tried his stuff with killing profiles.ini.

Axel
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
1234 ... 7