Office/ and Utilities/ menu reorganization

Christoph Cullmann cullmann at
Mon Aug 8 23:44:28 BST 2005

On Monday 08 August 2005 21:29, Matthias Welwarsky wrote:
> If the applications are "less important" they usually don't see a lot of 
> developer attendance anyway, meaning they're either fully matured or 
> unmaintained. Unmaintained applications tend to rot away because most of the 
> time it's not enough to just keep them compiling. You cannot keep the rot 
> from happening by just having them in a module.
Which is not true, like you see in the kde4/qt4 porting efforts, where lots of stuff is ported and fixed by people
which normally don't touch these apps, and which would have not happened with extragear apps, as there you
just can't do such stuff, as you don't even know, is the trunk there already aimed for qt4/kde4? does the maintainer now
want porting? ....

> For the mature apps I don't see a problem to factor them out, because they 
> don't see any more releases, so there's no work involved. For the immature 
> stuff, well, it should not have made it into a release anyway, so you don't 
> really want to waste time translating or documenting it.
? You are aware that there is actually something called "bug fixing", or?
Even apps which don't get any new features because they are "mature" or let say, because they
fit their purpose, needs to get fixes, needs to get adopted to kdelibs changes, ....
Do you really think that will happen if such little apps are outsourced?

> For the translators and doc writers its probably easier if the workload is a 
> little more evenly distributed over the year instead of having to work 
> overtime when a major release is due.
> Following your reasoning the best practice would be to have only one release 
> cycle for all of KDE, but that didn't work out in the first place.
But it has shown suitable for most apps to follow KDE release cycles, or have there been that many major problems?

> > Users who build from sources would have to keep track of more packages,
> > new dependencies, new build orders, etc.
> But on the other hand they'll have more control over what they actually want 
> to install instead of having whole modules of useless applications stuffed 
> down their throat. 
That's a packaging issue and like you say some easy scripts can make live easy enough for distributors to keep up with
many new small extragear apps, the same could be said that they can just split the packages into seperate rpms/debs
with some scripts, like debian already does.


Christoph Cullmann
KDE Developer, Maintainance Team, cullmann at

More information about the kde-core-devel mailing list