[Kroupware] Re: [PATCH] Fixes Bug 49802: vcard does not get displayed, kmail shows error instead

[Don Sanders]

On Thursday 28 November 2002 18:22, Cornelius Schumacher wrote:
> On Thursday 28 November 2002 07:47, Don Sanders wrote:
> > KMail and its dependent kdenetwork libraries need to be moved
> > into kdepim. Those dependent libraries are mimelib and
> > libkdenetwork (the later could do with a renaming). Other
> > kdenetwork apps that also rely on these libraries should be moved
> > into kdepim also.
>
> In how much code would this result? What would be the size of
> kdepim after moving KMail, its dependencies and the apps that
> depend on that? How would this compare to other KDE CVS modules?

Here are the size of some KDE source packages I have (in K):

kdebase 78616
koffice 52576
kdenetwork 32960
kdepim 27932
kdegraphics 22912
kdeutils 11260

Here are the size of the packages the need to be moved:

 mimelib 1480
 libkdenetwork 1672
 kmail 4188
 knode 1408
 korn 376
Total 9124

So kdepim would become 37056 K, swapping places with kdenetwork to be 
the 3rd largest KDE source package I have. I think that's ok.

> > This is because kdepim should be able to make independent
> > releases, like KOffice, and the users should be able to get all
> > there pim apps from one package.
>
> Distributions tend to split up the CVS modules for making packages.
> So what the user gets isn't necessarily defined by the structure of
> the CVS.

Sure, but I don't see that as being significant. I mean this doesn't 
alter my thinking that kmail belongs in kdepim. I'm concerned about 
what KDE does, not what other distributors do. The reason why kdepim 
was created was so that certain apps, like addressbooks, mail clients 
and organizers could all be put in the same package. Now that KMail 
has been made into a part and unified with its siblings it's just 
common sense to put it in the same package.

> About independent releases: I don't think it's a good idea to make
> independent releases of kdepim like KOffice does. We should take
> part in the normal release cycle, otherwise we would need a
> significant amount of additional work to organize the releases
> which I think is better spent on coding.
>
> This does not mean that it wouldn't make sense to make additional
> releases of parts of kdepim independently of the standard KDE
> release plan. For example we could release KitchenSync before 3.2,
> if it shows to be usable.

I would like to make independent releases of Kontact/Kaplan and the 
parts they contain. This is something that I am willing to do the 
work for.

> > Moving the KMail Part interface into kdelibs isn't a good
> > solution, as it means pim users will end up having to update
> > kdelibs to update kdepim, and that means they will end up having
> > to update all of KDE.
>
> As a developer you can update parts of kdelibs and you will have to
> anyway because libkabc is in kdelibs. Making a separate release of
> parts of kdelibs is certainly also possible, although it will
> require some additional effort.

These kind of dependencies are a hassle for users and they really 
should be minimized. I don't find the idea of a separate release of 
certain parts of kdelibs enticing.

But once kdelibs is stable enough I think separate releases of kdepim 
makes a lot of sense. I see separate releases as giving a clear 
indication that KDE has a pim suite that is unified and complete, 
that KDE PIM and KDE has matured to reach an important milestone.

> At the moment there is nothing like a KMail specific KPart
> interface, so we maybe should postpone the discussion about that
> until we have one.

I'm ok with postponing the discussion for the moment. But I think this 
move should be made well before 3.2. I'm willing to start the 
migration by moving KMail Cool and its dependencies into kdepim. I 
would like to do this once Kontact/Kaplan and its components are 
ready for distribution.

Don Sanders / sanders@kde.org
KMail  Adopter / kmail.kde.org
KDE PIM  Co-founder / kdepim.org
KAddressbook  Founder / kaddressbook.org
KDE  Contributor / kde.org