The kdebase purpose (Was: Re: Moving KMail, KNode, Korn and related libraries to kdepim)

[Marc Mutz]

On Wednesday 15 January 2003 12:51, Adriaan de Groot wrote:
<snip>
> Proponents of moving seem to base their arguments on counting the
> _number_ of dependencies, opponents count the size. I mean, if
> ioslaves move to libs, libs gets bigger and we're sure to get people
> whining about the size of libs then (I want to develop a KDE app but
> libs is so bloated with IOslaves, when all I need is libkdecore and
> libkio).
<snip>

I think one important point is left out of this summary. That of 
"external" development of KDE "core" applications (= apps shipped with 
KDE).

KMail is currently the only example I know of where this happened 
(khtml/Apple is different, since it was not developed in KDE CVS). But 
it has already happened twice.

Two things make developing projects like Aegypten and Kroupware harder:
1. Having to have branched subdirs in a lot of CVS modules, with only a 
few subdirs actually branched in each and
2. Fast removal of HEAD apps' ability to run on the latest stable libs.

(2) was a PITA for Aegypten and (1) is a PITA for Kroupware.

Both the KMail->kdepim and the kdebase-kio-slaves -> {kdelibs,kdepim} 
moves are inspired by the Kroupware project.

If KDE wants to keep such projects happening to it, it better started 
paying attention to minimization of cross-module dependencies and 
maximization of HEAD apps' compatibility with latest stable libs.

Not all "external" projects will go to such great lengths as to develop 
within the KDE community as Aegypten and Kroupware do, or to provide 
such detailed changelogs as Apple did! We have been quite lucky up to 
now.

<anecdote>
In fact, rumour has it there exists a second S/MIME-enabled KMail that 
has never been released nor has anyone of us ever seen it (I was 
approached by a guy on LT2k1 about it). It was developed in the dark 
and never came to light. Though it could _very well_ have been the 
KMail that the BSI would now use on governmental desktops, had the 
Aegypten consortium not won the bid back then.

And not releasing it back to us would have been perfectly legal, because 
the BSI ordered a _solution_ not a product. BSI couldn't release the 
solution (= that other KMail) to anyone outside the German Government, 
of course, b/c that would violate the GPL, but ok, then they simply 
wouldn't have done it...
</anecdote>

OK, what I wanted to point out is that it does, in fact, matter what the 
inter-module dependencies are in KDE. It's not only the distributors' 
problem. It should also be ours.

Marc

-- 
The [Sonny Bono Copyright Term Extension Act] expands copyright not
only for future, but also for existing works, even though their
authors obviously don't need any additional incentive to create them.
                -- "The Progress Of Science And Useful Arts":
                    Why Copyright Today Threatens Intellectual Freedom,
                   Free Expression Policy Project
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030115/6b89c75c/attachment.sig>