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?

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.

Accepting.

moving to M16

I understand that this may be a cut feature. up to cathleen for the punt, or redelegation.

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.

how about under: http://www.mozilla.org/profilemanager/

moving to m30 out for beta2, decision made by all parties involved in profile migration.

Parcelling out Cathleen's bugs

Changing fictional "M30" to reality

May be a future feature. Dropped for initial release of Seamonkey. (Confirmed by marketing (Bijals@netscape.com) Marking LATER.

.

Why not use helpwanted? Someone in the Mozilla community might pick this up, and I doubt netscape.com marketing would turn it down. /be

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?

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

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

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

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.

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.