Closed
Bug 23090
Opened 25 years ago
Closed 9 years ago
[feature] Migrate in place with copy/diverge choice
Categories
(Core Graveyard :: Profile: Migration, defect, P3)
Core Graveyard
Profile: Migration
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
Future
People
(Reporter: kevinyen, Unassigned)
Details
(Keywords: helpwanted)
Attachments
(1 file)
7.96 KB,
text/html
|
Details |
In the comments/thread for 18118, two needs were expressed for migration:
1. We should give people the choice of not migrating a 4.x profile to 5.0
2. We should not automatically consume many megabytes of disk space w/out user
choice (which the automatic copy migration once did).
These are very valid requirements, and have been addressed for M14 per bug
18118. But we can address them even better in M15, as some people have
suggested.
Basically, copying/diverging as a means of migration is suboptimal, since the
files to copy (e.g., mail) can be many, many megabytes. It would be great if a
user could migrate but have the files migrated with a "move" rather than a
"copy". This would minimize the space required.
So, let's migrate in place (migrate with a "move" instead of a "copy"). Since
most people will want to migrate this way, this will be the default. (These
migrated profiles will still be accessible from 4.x, with some simple hacking.)
But even with the improved "move", some don't want to migrate or want to migrate
using the copy/diverge. So let's offer these choices as well.
So, to summarize, let's do the following to meet the needs of different people:
1. Default action: Migrate in place (can still use 4.x to access migrated
profiles, though some hacking might be needed)
2. Give user choice: In Installer dialogue under Custom, allow choice of not
migrating and migrating using copy/diverge.
If this sounds fine, then the next step is to create specific bugs for the
relevant modules (installer, migration, etc.), so that this bug would become the
tracking bug.
thx,
kevin
Comment 2•25 years ago
|
||
adding myself to the cc list.
Comment 3•25 years ago
|
||
kevinyen, please post to the newsgroups about the new design.
Comment 4•25 years ago
|
||
I think the disk space argument is extremely weak, since you can now buy disks
for less than a penny per megabyte. It is much more important to keep things
simple and problem-free for the user. I think it is just too risky to have your
existing 4.x profile modified by pre-alpha software. I doubt most users will
understand the risk. After trying Mozilla, if they then have problems using
their old profiles under 4.x, could very easily just switch to IE.
Comment 5•25 years ago
|
||
There gonna switch to IE because of stupid crap like this, shopping buttons,
spam in their inbox, etc. a great deal more. Trust me. I am in the Netscape
Communicator group daily for more than 2 years. These kind of crap is exactly
why people don't like Netscape any more.
As far as disks being cheap; is Netscape then volunteering to purchase hard
disks for those that do not have the space? And since when did Netscape get to
decide the best use of *MY* disk space?
Updated•25 years ago
|
Target Milestone: M15
Comment 6•25 years ago
|
||
We're talking about pre-release software, not the final version. Beta users
should still be in control of whether the profiles are migrated, but I think
that offering to put all of their data at risk to save a few pennies worth of
disk space is not something we should consider for any beta version. Anyone who
cannot spare a few pennies worth of disk space can always choose to not run the
beta software.
Can we please take this discussion out of the bug report and either put it on
the newsgroup or at least email?
Comment 8•25 years ago
|
||
Anyone who is not willing to put their data at risk should not be using
pre-alpha (or alpha, likely) software in the first place. That's why we have
the warning at the top of http://www.mozilla.org/binaries.html. (Maybe the
"rules" for Netscape betas are different, in which case those differences should
-- and do, IIRC -- appear in the Netscape tree.) If they want to play with
their 4.x profiles, I think that should be up to them -- how do you know that
they even care about their 4.x profiles? On my NT system, I have a user for
testing Mozilla, and I assure you that the 4.x profile data for that user isn't
worth protecting from any Mozilla mis-step.
So far, I have not heard from any users who want silent automigration, and I
have heard from users who don't. Seems like an easy call, at least until
someone publishes the data that led the Netscape group to make their decision,
so that the Mozilla community can decide if they agree with the reasoning and
whether or not they reach the same conclusion.
But that's why we're going to do this in the newsgroups, right?
Comment 9•25 years ago
|
||
what newsgroup?
Comment 10•25 years ago
|
||
.seamonkey or .ui, I would say -- maybe both.
Comment 11•25 years ago
|
||
In response to comments above by Shaver, although there are caveats for beta
users, we should always go to great extremes to protect beta users from damage,
just as we should in FCS products. If we, the folks that write the code, don't
feel confident about the code, we should exercise care to prevent injury to
testers. IMO, a few bad experiences (one really bad one) can cause testers to
not want to help anymore. You can argue that the "Copy" activity is a "bad
experience," but it is no where near as bad as a "Deleted my whole folder, and
lost a ton of critical email" experience.
By the time we reach FCS, we had better be proud and confident in our code, and
at that point (or in some beta before then), we should expose full functionality
to users. Until then, it does no one good to expose insufficiently tested and
potentially harmful code (without special warnings etc.).
I think we already have a proposol in hand that will help with the "bad
experinece" of an undesired "copy" (giving users the choice if they want
advanced selections).
Having handled customer support for some testers, I'm quite happy that we don't
push these questions into the face of the more simplistic tester.
Comment 12•25 years ago
|
||
I have posted comments and a reference to this bug under the
existing thread "Automigration of a single profile" in the n.p.m.seamonkey
newsgroup as a reply to the top-level posting in that thread.
Comment 13•25 years ago
|
||
Accepting.
Summary: Migrate in place with copy/diverge choice for M15 → [feature] Migrate in place with copy/diverge choice for M15
Comment 15•25 years ago
|
||
I understand that this may be a cut feature. up to cathleen for the punt, or
redelegation.
Assignee: dbragg → cathleen
Status: ASSIGNED → NEW
Comment 16•25 years ago
|
||
it was decided that we were going to stick with copy and diverge.
varada wrote up a document about the choices and the decision.
varada, can you add a link to that document in this bug report.
one day, migrate in place may happen, so this should probably be marked later or
wontfix.
Comment 17•25 years ago
|
||
The link to the doc is in http://jazz/users/varada/publish/migration.html
Comment 18•25 years ago
|
||
Varada, could you publish that doc somewhere outside the firewall? Thanks.
Comment 19•25 years ago
|
||
how about under: http://www.mozilla.org/profilemanager/
Comment 20•25 years ago
|
||
moving to m30
out for beta2, decision made by all parties involved in profile migration.
Target Milestone: M16 → M30
Comment 23•25 years ago
|
||
May be a future feature. Dropped for initial release of Seamonkey. (Confirmed
by marketing (Bijals@netscape.com)
Marking LATER.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → LATER
Comment 25•25 years ago
|
||
Why not use helpwanted? Someone in the Mozilla community might pick this up,
and I doubt netscape.com marketing would turn it down.
/be
Keywords: helpwanted
Comment 26•25 years ago
|
||
Also, Mfuture can be helpful
Comment 27•25 years ago
|
||
Mozilla has a marketing department?
Comment 28•25 years ago
|
||
Sure, whatever.
Comment 29•25 years ago
|
||
Can we get the document that was requested by Shaver in April out into the
public please.
Comment 30•25 years ago
|
||
I think the odds of seeing that document drop with every passing day.
Comment 31•25 years ago
|
||
We'll review it for posting ASAP. Sorry for the delay.
Comment 32•25 years ago
|
||
(I cannot access the discussion, <snews://news.mozilla.org> expires.)
I agree with Netscape that it is not desireable to "move" profiles for a beta
version. As I beta tester, I would not expect this. Our profiles are not stable
enough to justify this yet *as default*. The option to do so would be nice,
however.
I completely agree the Mozilla should have the option to not use 4.x' profile at
all.
Also, shouldn't helpwanted bugs be open?
Comment 33•25 years ago
|
||
Comment 34•25 years ago
|
||
Thanks for the attachment. I thought that document was going to describe why
there is no choice whether or not one migrates, not what is to be done if a
migration is to occur.
Comment 35•25 years ago
|
||
Reopening; otherwise people who search for helpwanted bugs won't see this one.
Milestone "Future" has replaced the "Later" resolution.
AIUI, this bug is asking for two things:
1) Option not to silently import 4.x profile (if there is only one; dialog
already appears if there is more than one.) This could be implemented by simply
getting the Manage Profiles dialog to pop up in all cases, I think. Or something
like that.
2) An option to migrate your NS 4.x profile and delete it afterwards. This
should also be easy - one toggle switch and a "delete folder" command. This
would be easier than doing a "move" IMO, and the result is the same.
Is that right?
I'm still not clear, though, on how "migrated" profiles can still be accessed
from 4.x, as kevinyen asserts. Aren't the formats different?
Gerv
Status: VERIFIED → REOPENED
Resolution: LATER → ---
Updated•25 years ago
|
OS: Windows NT → All
Hardware: PC → All
Summary: [feature] Migrate in place with copy/diverge choice for M15 → [feature] Migrate in place with copy/diverge choice
Comment 36•24 years ago
|
||
I'm still interested in that document, FWIW.
Comment 37•24 years ago
|
||
Nominating for mozilla1.0 for my 1) above - option to not silently import NS 4.x
profile by bringing up the "Manage Profiles" dialog in all cases.
Gerv
Keywords: mozilla1.0
Comment 38•23 years ago
|
||
In addition to Gerv's summary: shouldn't this bug also cover giving the user an
option not to migrate at all (i.e. create a new mozilla profile with all default
values)? Or is that covered by some other bug?
Comment 39•23 years ago
|
||
Actually, I don't see this for moz 1.0. The way things currently work was
reached after much discussion of this topic and reopening that discussion now
will only be distracting and counterproductive. Leaving the bug open and
targeted at future is fine though.
If any checkin results from this bug, please be sure that it doesn't regress any
of the expected behaviors in either the Mozilla or Netscape products (obviously
the latter is the responsibility of Netscape employees.)
We have to have more important things to do right now. If you disagree, look at
Brendan's manifesto or talk to him.
Comment 40•23 years ago
|
||
This needs to be reassigned to whoever is working on migration issues.
selmer, do you know who that is these days?
Comment 41•23 years ago
|
||
Seth, can you find the right home for this? If there's any remaining issue,
it's centered around mail migration. My first thought on rereading this was to
close it as wontfix...
Assignee: dbragg → sspitzer
Status: REOPENED → NEW
Comment 42•23 years ago
|
||
Mass removing self from CC list.
Comment 43•23 years ago
|
||
Now I feel sumb because I have to add back. Sorry for the spam.
Comment 44•18 years ago
|
||
sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
Updated•15 years ago
|
QA Contact: agracebush → profile-migration
Blocks: 1243899
Comment 45•9 years ago
|
||
This bug is filed in a bugzilla component related to pre-Firefox code which no longer exists. I believe it is no longer relevant and I am therefore closing it INCOMPLETE.
If you believe that this bug is still valid and needs to be fixed, please reopen it and move it to the Toolkit:Startup and Profile System product/component.
No longer blocks: 1243899
Status: NEW → RESOLVED
Closed: 25 years ago → 9 years ago
Resolution: --- → INCOMPLETE
Assignee | ||
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•