Alex Schuster posted on Tue, 28 Jun 2011 23:24:58 +0200 as excerpted:
> I did the big KDE 4.6.3 -> 4.6.4 upgrade. Along came the change to
> KDEPIM 4.6. I feared for the worst, and indeed, it didn't work too well.
Your experience mirrors mine to a large extent. AFAIK we're both on
Gentoo.
Put it this way, I can see why they were reluctant to release kdepim 4.6,
even years after the intended initial release (it was supposed to be
ready for kde 4.0, originally, from what I've read) and over a year plus
after the "slid"-but-still-only-address-book-ported release of 4.4. I
had been hoping all the extra time had it now fully stable, conversion
tested, etc, but honestly, while it's *NOT* as bad as early kde4, at
least this feels like beta software, not alpha, and I've NOT seen anyone
INSISTING that it's stable and ready for normal use when plain experience
demonstrates otherwise, and forcing upgrades due to dropping support of
the previous, yet, as happened with kde4, it *DOES* still feel beta, even
after all these years trying to make it work. But in a way that's OK, at
least here, as I've always considered myself an early adopter and
routinely do adopt upgrades at the beta stage.
Here, I don't use the kontact suite (nor have kontact itself installed)
at all, only some of the separate bits. No korganizer, tho it was a
forced install with the update, no kalarm, no knode (I run pan instead).
I do run akregator, which apparently has NOT been "akonodified" (yet?),
and I do, at least for the moment, run kmail (I eventually got the
mailstore upgrade done to my satisfaction but I'm honestly wondering if
it's worth the continuing hassle of akonadi), with a local "sysmail"
maildir and with a number of pop3 remote accounts on two different
servers, no imap at all.
The first-run kmail backing store upgrade went entirely haywire. It
warned that the import might take awhile, then took almost no time at
all, as if it couldn't actually see the old mail location at all, and I
ended up with an entirely empty set of default folders, nothing more,
altho the account information itself DID apparently transfer OK, and of
course the address book was still there as it had already transferred
with 4.4.
The problem, it seems, was that I had kmail (1) set to use a different
directory for its mail. What? After ALL this extra time, much of it
spent, we were told, on getting the conversion right, it couldn't do a /
simple/ thing like read the old kmail config and see where the local
mailstore was? This does NOT seem like the smooth experience I expected
after a year's extra delay, much of it focused on the converter. More
like the experience one might expect from a beta. Oh, well, I'm used to
running betas and dealing with this sort of stuff, no problem, if it can
import properly once I point it at the right place.
But since it hadn't imported it anyway and because there was a warning i
the importer about reimporting the in-place running working dir possibly
creating an endless loop (that's how I interpreted it anyway), I took the
step of moving the old mail store off of home, to my large media and
backup partition, leaving more room in home and an empty previous working
location, just in case. That did seem to make things easier, or at least
less confusing for me, trying to keep straight which was the new data and
which was the old data and ensure that I wasn't going to somehow trigger
this loop.
Meanwhile, I had deliberately not entered my kwallet passwords so the
remote pop3 accounts, which it DID import properly, couldn't download new
messages to local storage that wasn't setup correctly yet. With about
six accounts spread over two servers, the periodic kwallet popups and
manual entry popups when I canceled that, for each of them, got
irritating, but there wasn't much I could do about it as I wanted any
incoming mail left safely on the remote server until I was sure the local
storage wasn't screwed up.
The second (maildir) import attempt went better, but crashed half way
thru, apparently because some of the old mail folders were in mbox
format. (I had tried switching to maildir some years ago, and that was
the default, but found no way to switch the default folders as I couldn't
delete the old mbox folders in kmail after I'd copied everything to the
new maildir folders, so the defaults stayed as mbox, and continued to
accumulate some mail, altho filters moved most on receipt to sorted
maildir folders. And, I had missed a couple non-defaults as well,
including my family mail folder, which was still in mbox format.)
The *$#!$& maildir importer was trying to import the mboxes, including
the huge family mbox, as *SINGLE* *HUGE* *MULTI-GIG* mails, one for each
mbox!!
Again, that sort of mistake is acceptable for a beta, but NOT what I
expected from an importer that had been the focus of a year's delay, to
"get it right", ESPECIALLY when they're importing their own previous data
store and *KNOW* that the previous version could well have a mix of mbox
and maildir format, due to switches between the default formats over the
years and the fact that it continued to work with both. Further, a
situation like mine where someone had tried to convert to maildir but
couldn't delete the old default mboxes when kmail was running, so
couldn't convert at least THOSE dirs, could certainly have been predicted.
Meanwhile, akonadi/kmail was for some reason giving me warnings (similar
to those you saw) about missing folders for some of the stuff, even when
I could see them plain as day, browse them, etc, in kmail!
But just as I feared after seeing the warnings, quitting kmail and
akonadi, then restarting, often left the things disappeared.
Again, extremely rough beta quality. DEFINITELY not the sort of
experience a regular user should need to worry about, and DEFINITELY not
the sort of experience one might be lead to expect knowing they spent an
extra YEAR PLUS focusing on this stuff.
One can only shudder at what the experience must have been like BEFORE
the extra year of work... <shudder>
Meanwhile, after some manual rooting around viewing the old backing-store
in a file manager and various files, particularly the mbox files, in a
text editor, I figured out that the maildir importer was indeed trying to
import the mbox files as single HUGE mails, figured out which ones they
were and deleted the huge "mails" that it had managed to import into
kmail, and used the mbox importer to try to import them correctly.
Then I tried moving the kmail folders from their import locations to
where I really wanted them in kmail, resetting the filters to match the
new locations, etc.
Then I restarted kde, and found out much of the work disappeared on
restart, apparently due to those missing folder warnings I had been
getting.
But I'd evidently learned enough in the process that try #3 went far
better. After deleting the mess and restarting kmail/akonadi, and
manually moving the mbox files out of the maildir structure in the old
backing-store, so I could import the maildirs without the importer trying
to treat the mboxes as a single HUGE email, then separately import the
mboxes, it worked. This time without actually moving them to where I
wanted, yet, I shut kmail/akonadi down and restarted it, THEN moved the
dirs around, shut down and restarted kmail/akonadi again, and pointed all
the filters at the correct folders, shutdown/restart again, several times
now to make sure it's working reproducibly without errors, *THEN* tackle
the remote accounts.
The remote accounts had their own problems. Apparently kmail and akonadi
were fighting over who got and stored the passwords, which I had to
reenter in kwallet as the akonadi setup couldn't simply use or auto-
import the existing kwallet stored username/password info.
Eventually, I figured out more or less by trial and error that things
worked better if I ignored the mail password queries and setup the
accounts first in akonadi. One would THINK somewhere in the setup
there'd at least be a dialog explaining that setting up akonadi's
accounts first would work better, ESPECIALLY after all the extra time
they've had to work on this and get it right, but... well, I'm a beta
testing type of guy, so I could and did cope with it. But I shudder to
think about an ordinary user trying to deal with all this!
Meanwhile, even after getting everything setup apparently correctly, the
thing **STILL** can't manage grabbing mail right the first time after a
reboot or kde or akonadi restart. The problem appears to be that akonadi
isn't designed to properly handle two remote pop3 servers at the same
time.
So when I first grab mail, it pops up the kwallet password dialog as
expected, and I put in my password. It syncs the (one account on) one
pop3 server and local sysmail, but the multiple accounts on the second
pop3 server sit there, if I let them, for hours, syncing slider going
back and forth, back and forth, but nothing else happening.
If I hit the checkmail again, or when the periodic check comes due for
the whole set, it blocks, waiting for those frozen mailchecks that never
complete.
I must manually cancel the frozen mailchecks and trigger a new global
mailcheck, after which I get a SECOND kwallet password popup, which if I
enter my kwallet password, now grabs the password info for the accounts
on the SECOND pop3 mail server and checks them successfully.
Only after performing this kabuki dance at EVERY kde/akonadi restart,
putting in the kwallet password to get the passwords for the accounts ont
he first pop3 server, opening kmail and canceling all the mail fetches
for the second pop3 server accounts that will never get anywhere because
they're waiting on a kwallet dialog that never appears, manually hitting
fetchmail again, and entering the kwallet password a second time so
akonadi/kmail can access the accounts on the second pop3 server, does it
all work correctly. I must do this EVERY time I restart the computer, kde
or akonadi.
And while I'm getting no errors now, and mail seems to come in, the whole
experience, all the bugs, all the beta-quality stuff and missing
attention to details triggering stupid stuff like the kabuki dance I have
to go thru every time I restart kde/akonadi, even after YEARS of work,
all of that, has left me wondering at the stability of the whole setup.
What's so wrong with plain maildir and mbox, after all? Both are common
standards used across many clients, and it certainly seemed more stable
with that, than all this does, even after YEARS of work to "get it right".
And I've left out all the stuff about properly configuring akonadi
resources (what you appear to be dealing with), etc, along the way.
Oh, and the fact that despite the fact I don't need it, I now have
korganizer, and despite the fact that I don't need nepomuk calendar/alarm/
search integration and in fact turned nepomuk off as a result, now I get
multiple notifications at every boot about stuff I deliberately turned
off because I don't need or want it, with no visible way to turn off the
stupid warning notifications for stuff that's useless to me!
I really, honestly, have a hard time believing it's all worth it. I had
wondered about switching from kmail before, with all this stuff on the
horizon, but despite the minor hiccups switching to the akonadified
addressbook, for the most part it still "just worked", without getting in
my face, and I decided I should at least give the new stuff a try, once
it came out.
Well, I've given it a try now, and I honestly can't see how all that
hassle was worth it! Plus, I'm now living in constant fear of the
dreaded akonadi can't-find-the-folder errors and the like, wondering if
my mail's actually safe, or not. If it can lose whole FOLDERS, if the
converter can't tell the difference between mbox and maildir and imports
mbox as single HUGE mails as a result, if it can't ask ONCE for the
kwallet password, or at LEAST ask twice in a row if it must, without me
having to manually cancel about a half-dozen mailchecks that will never
complete and retrigger a mailcheck so I can enter the kwallet password a
second time... even after an extra year plus to get it right... what sort
of faith can I have that it's not going to lose mail on me? Answer, no
faith. At least the previous setup "just worked", only needed one kwallet
password popup, and had a demonstrated reasonable reliability I didn't
have to worry about. That's definitely NOT the case with this new,
"fancy" thing!
Which leaves me wondering just what mail client I should think about
trying next. Why couldn't they have left what was working just fine,
well enough alone?
Will I still be on kmail a year from now? I honestly don't know.
Despite the forces of inertia now that it seems to be at least sort-of
working, I'd put the chances lower than they've ever been before, at
perhaps 40-50%. And if there's just one major "event"... The question
I'm asking myself is will it take such an "event"... or I be proactive
and get off the platform, before such an "event" happens?
It's really, **REALLY** a shame that it has reduced to THAT level, from
what kmail /was/ and still could be, a quite good solution for me
(possibly because I only do pop3, no imap, I know) that I had no reason
to contemplate moving from, but what can I say?
I'm *NOT* looking forward to looking for another mail client, but it
seems I'm being forced into it, much as MS forced me into switching to
Linux with the line they crossed with "anti-features" in eXPrivacy. Of
course, I can only hope the result will be so good! Certainly today, I
can only thank MS for giving me that final push toward the land of
freedomware! If I'm lucky, perhaps in a year or two I'll be saying the
same about the push the kmail/kdepim guys gave me toward whatever new
mail client I might find. <shrug>
Or maybe I'll tempt fate and stick around, and if I'm lucky, no such
"event" will happen, and the kmail experience will gradually improve once
again, much as has the kde experience. The question is, am I willing to
tempt fate on whether an "event" will happen, or not? Because that's
exactly the level of faith I have in the stability of the current setup.
Were it not for that, I'd certainly stick around for it to get better,
just as I did for kde4 itself, and I expect it will, just as it did for
kde4. But even then, I'm not sure the stability is there; even if they
fix all the UI issues and introduce lots of fancy new features, an
"event" could yet happen, a year, two years from now. And honestly, I'm
*NOT* impressed by how kmail/akonadi/the-converter handled the "events"
that happened in the conversion, when I had no new mail to get lost in
the process, as I will a couple years from now.
I guess time will tell...
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
