Closed Bug 23090 Opened 22 years ago Closed 6 years ago

[feature] Migrate in place with copy/diverge choice

Categories

(Core Graveyard :: Profile: Migration, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED INCOMPLETE
Future

People

(Reporter: kevinyen, Unassigned)

Details

(Keywords: helpwanted)

Attachments

(1 file)

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
Adding Michael Laguardia to cc list.
adding myself to the cc list.
kevinyen, please post to the newsgroups about the new design.
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.
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?
Target Milestone: M15
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?
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?
what newsgroup?
.seamonkey or .ui, I would say -- maybe both.
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.
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.
Status: NEW → ASSIGNED
Accepting.
Summary: Migrate in place with copy/diverge choice for M15 → [feature] Migrate in place with copy/diverge choice for M15
moving to M16
Target Milestone: M15 → M16
I understand that this may be a cut feature.  up to cathleen for the punt, or 
redelegation.
Assignee: dbragg → cathleen
Status: ASSIGNED → NEW
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.
The link to the doc is in http://jazz/users/varada/publish/migration.html
Varada, could you publish that doc somewhere outside the firewall?  Thanks.
moving to m30
out for beta2, decision made by all parties involved in profile migration.
Target Milestone: M16 → M30
Parcelling out Cathleen's bugs
Assignee: cathleen → dbragg
Changing fictional "M30" to reality
Target Milestone: M30 → Future
May be a future feature.  Dropped for initial release of Seamonkey.  (Confirmed 
by marketing (Bijals@netscape.com)

Marking LATER.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → LATER
.
Status: RESOLVED → VERIFIED
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
Also, Mfuture can be helpful
Mozilla has a marketing department?
Sure, whatever.
Can we get the document that was requested by Shaver in April out into the 
public please.
I think the odds of seeing that document drop with every passing day.
We'll review it for posting ASAP. Sorry for the delay.
(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?
Attached file Profile Migration
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.
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 → ---
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
I'm still interested in that document, FWIW.
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
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?
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.
This needs to be reassigned to whoever is working on migration issues.  

selmer, do you know who that is these days?
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
Mass removing self from CC list.
Now I feel sumb because I have to add back. Sorry for the spam.
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
QA Contact: agracebush → profile-migration
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: 22 years ago6 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.