kdepim release (Was: Re: [Kde-pim] KDE 3.3 Release Plan is up)

Bo Thorsen bo at klaralvdalens-datakonsult.se
Mon May 10 09:52:17 BST 2004


I will try summing up all the discussion here, and add my own points to 
it. The kdepim discussion has been focusing too much on the user point of 
view, but that's not all of it. There are several reasons why staying 3.2 
compatible is a good idea, and a couple of problems with it.

Pros:

- More stable environment for the developers. This is such an important 
thing for us pim people, since most of us are only developing in kdepim. 
It's incredibly annoying to stay on HEAD for something your not focusing 
on. Someone claimed this is a stability problem for libs, but I fail to 
see that. If you're on the bleeding edge, sometimes you bleed. But the 
pim people just want to code the pim apps with less hassle and use the 
libs.

- Less upgrading for users. This is *not* a small deal in corporate 
environments. But people (me somewhat included) who thinks certification 
processes are borderline stupidity has problems accepting this. Putting 
on the KDAB hat and thinking as a proko2/kolab2 project manager, this is 
a great move towards making commercial backing of kdepim possible.

- As KDE has grown bigger, it has become an increasingly big problem to 
get it released. Separating the release of kdelibs/base from the rest 
will do a lot towards making the freeze period smaller and less 
intrusive. Andras asked, what makes it such a different part than the 
rest of KDE. Well, it's not. But this move goes towards the same 
separation as KOffice and KDevelop has. You can see it as a move towards 
splitting libs/base from the applications.

There are more pros for me, but those are IMHO the most important.

Cons:

- Won't be able to use new libs features. Sometimes this is just annoying, 
other times it's a real problem. Especially the fact that KABC and the 
resource stuff are in libs is a potential problem. New widgets in libs is 
something that a lot think is extremely cool and something you can't live 
without. But with the quality of libs, that's just no longer true. We 
actually do get sleep at night without the latest and greatest widget :-)

- Releasing KDE as one big thing does have a lot of things going for it. 
Users know exactly what fits together and never has a problem figuring 
out dependencies. Also, from a marketing point of view, this is a much 
easier message to tell.

- The i18n release is so far an unsolved problem. I have absolutely no 
clue how to get this solved for 3.3 :-(

Finally, someone mentioned bugfixing as a an item for the cons - that 
kdepim won't benefit from the latest bugfixes. That's actually an 
argument for people being bad at backporting! And the counter argument is 
of course that kdpeim won't benefit from the latest bugs :-) This 
argument goes both ways.

I believe the whole argument can be boiled down to one single question:

Is kdepim part of KDE or does it use KDE as a platform?

In this question, "part of" is of course a bit undefined. When you think 
about it, you should keep KOffice and KDevelop in mind - for those the 
answer would be they use the platform.

I believe that after the i18n problem has been solved, the split will be a 
great thing. I only see one real problem with it, and that's the point 
that one big KDE is easier for users to figure out. Everything else is 
speaking for a split.

Bo.

-- 

     Bo Thorsen                 |   Praestevejen 4
     Senior Software Engineer   |   5290 Marslev
     Klarälvdalens Datakonsult  |   Denmark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040510/e61218d5/attachment.sig>


More information about the kde-core-devel mailing list