On Tuesday, 2012-06-19, Modestas Vainius wrote: > There is nothing wrong with having "old KDE inside" if it works. That said, > I don't claim that pim 2 does not work. We simply don't know it and it's > too late in the game to find out (IMHO). Inexistance of a good migration > tool helps to make the decision though. > > FWIW, I'm pretty sure that migration won't ever be fixed. However, users > will have more time to adjust at the start of the next release cycle. What > is more, I think somebody will be kind enough and upload kdepim 4.8.4 to > backports and wheezy users will have the best of two worlds (a choice) in > the end. The main problem with the migration tool is that the complexity of the mail setup just does not fit into the constraints of the migrator framework used for other data types. I.e. for other data types it is sufficient to create one new backend connectors for each old backend connector and transfer the respective config. Mail setup has folder specific config, folder and mail item specific meta data, etc. which requires the migrator to do a lot of mail structure and data processing. This also takes way longer than what is acceptable for a migrator that runs automatically on first application start. The correct solution is to make KMail2 start immediately but empty and detect and offer import choices. Cheers, Kevin
Attachment:
signature.asc
Description: This is a digitally signed message part.