[Kde-pim] From a users point of view ....

Martin Steigerwald Martin at lichtvoll.de
Thu Feb 23 20:57:58 GMT 2012


Hi Mike!

Am Donnerstag, 23. Februar 2012 schrieb Mike McGinn:
> On Thursday, February 23, 2012 07:43:45 Martin Steigerwald wrote:
> > Hi Kevin!
> > 
> > Am Mittwoch, 22. Februar 2012 schrieb Kevin Krammer:
> > > On Wednesday, 2012-02-22, Mike McGinn wrote:

[… removed stuff that was unrelated, cause I answered to Kevin Krammer here 
…]

> Hi Martin,
> Thank you for your reply.
> I started using KDE and Kmail in 2004 with the old Mandrake
> distribution. I have gigabytes of mail and contacts. I have over 200
> filters set up to filter incoming mail.

And now what?

martin at merkaba:~> du -sh Mail
14G     Mail
martin at merkaba:~> find Mail | wc -l
433023

Its way more mails, cause I use big mbox files for archival. It could 
easily be a million mails.

And it works. With KDEPIM 4.4.5. With the limitations of the old KDEPIM I 
got accustomed to.

I am really looking forward to KDEPIM 2, but from what I gathered here and 
elsewhere I will give it a bit more time to mature.

> When I was using Kubuntu and Ubuntu 8.04, everything worked great.I
> didn't think about my PIM, and I don't want to have to think about it.
> 
> When I upgraded to the new KDE paradigm and akanodi, I lost my mail
> account settings - which was no big deal. I lost all my filters too,
> which was a major pain.
> 
> Now I am using 10.04. I had to add a hook to my KDE login to start
> akanodi when I logged in, or else my contacts would not be accessible
> when I started Kontact. There are also some plugins (like Google
> Calender) which I have never gotten working, so I gave up on them.
[…]
> When a user chooses a distribution and software that is advertised as
> being user friendly, it should just work. It is an incredible hassle
> to have to work around things that are not working properly. Some of
> us actually use our computers for work. I run a server farm for an
> internet company and I am the treasurer for my congregation. I do all
> of that on the very laptop that I am typing this message on. I do not
> think my expectations are too high when I expect released software to
> work.

I think communicating KDEPIM 2 as being ready for production use has been 
premature. And from what I read from the KDE Promo team and some other 
mails at least some KDE developers seem to agree meanwhile. And yes, a 
understable reaction to this is being disappointed and frustrated.

But - at least to some extent - its still the choice of the distribution 
what versions of what software to include. Its possible to still provide 
KDEPIM 4.4.5 even up to KDE SC 4.7.4 and I bet even up to KDE SC 4.8. This 
might not be perfect, but it works for the time being. At least for me it 
does.

If you are not satisfied with the choice that Kubuntu developers made, 
either ask them to correct their choice or use a different distro. When 
Kubuntu developers deem that it is suitable to put KDEPIM 2 into a LTS (!) 
release you do not have to agree. Actually I do believe that KDEPIM 2 for 
the time being has nothing to do in enterprise or long term support 
distributions at all from what I read here and at kdepim-users.

I am still using KDEPIM 4.4.5 and it works quite well for me. Debian 
Qt/KDE developers for example do not yet provide KDEPIM 2 packages 
officially and I am pretty sure that is not cause they could not.

If you need a software for production work and you find out that it is not 
suitable for production work for you even when it was advertised as such, 
its understandably that you feel frustrated.

But nonetheless what kind of action would help you to change your 
experience more?

1) complain here and demand  - best immediate - fixes of all pressing 
issues without paying anyone a dime for it while still continuing to use 
the software that you consider not to be production ready and thus 
inflicting more pain onto you or

2) use something thats stable

From what I read on this list, I bet that KDEPIM developers are painfully 
aware that KDEPIM 2 has serious issues. What do you think you will achieve 
by making them aware what they already know? I do think: Nothing. Or even 
the opposite of what you want to achieve.

How do you think it would feel when you put lots and lots of work to 
refactor your software from the ground up cause you believed that it would 
be a great long term benefit and then be told that your software is crap or 
broken by design and you have to fix it immediately? Would that motivate 
you to fix it? (Independently whether it has been wise to do the 
refactoring or not. I still think it will turn out being a good decision 
in the long term.)

And even when you find a software being crap for you it might still work 
for some.

And then look at KDE 4.0 versus KDE 4.8? Did KDE 4 evolve? Did it get more 
mature, more stable, more pleasure to use?

I am pretty sure that KDEPIM 2 will become a really good KDEPIM suite. 
Using a database for PIM metadata has been done elsewhere like in Zimbra - 
successfully. Until it has reached this state for you, you have the option 
to bear with it and help making it better or leave by staying at an older 
version or using another mail client - at least temporarily.

It again is as simple as that.

Why do you insist on having pain when you know that it is not necessary as 
I explained to you partly by repeating what I already wrote? If using 
KDEPIM 2 is too much for you for your production work then don´t use it. I 
fail to understand what is sooo difficult to grasp about that.

Staying at an older version seems to be less painful for me with the ton 
of folders, ton of mails, ton of filter rules, ton of settings and an 
integrated CRM114 spamfilter I use KMail with. It might be less painful for 
you as well.

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/


More information about the kde-pim mailing list