Office/ and Utilities/ menu reorganization
lofi at freebsd.org
Mon Aug 8 20:21:31 BST 2005
On Monday, 8. August 2005 20:05, Thiago Macieira wrote:
> Michael Nottebrock wrote:
> >It would probably make release management quite a bit easier for
> > everyone involved if KDE would lose a substantial portion of the
> > applications it's currently shipping instead of keeping adding new
> > ones. Kdeextragear is very much the way to go there.
> I don't see your logic here.
> The developers and maintainers would have to do the release management,
I.e. create a tarball every once in a while and make it available for download
somewhere (and KDE could simply provide ktown-access/space to keg-application
developers for that purpose). That's hardly stressful compared to developing
and maintaining an application in the first place.
If there's any sort of demand for the actual application, distributors or
users will take care of the packaging. That's assuming you're actually
talking about binary packages here and not tarring up the source, if so, see
> and annoucement.
Application maintainers already have to provide changelog entries themselves
and KDE.org already features application announcements from kde-apps.org on
> The translators and documentation writers would have to keep track of
Perhaps a translator or documentation writer could comment on that. The way I
see it, it would actually reduce the workload of the *KDE* translators and
documentation writers and possibly even improve the
translation/documentations of the respective individual applications, because
they would attract their own, more focused crowd of translators and
> The packagers would have to keep track of new releases,
Hardly a problem.
> more dependencies
I can't follow you here.
> and more build scripts to maintain.
Actually it would enable most packagers to get rid of all sorts of shimmies
they need to employ right now to provide a standalone package of an
application that's embedded in a KDE module.
> For a user of a distribution/OS that doesn't split packages, that's more
> packages to install and keep track of.
You can't make a general statement like that - for instance if a user just
installs an hypothetical Ark package, but not any other of the applications
which right now reside in kdeutils, the number of installed packages remains
constant, but the number of installed applications and K-Menu entries is
If you take a look at how many distributors of KDE *do* split the modules into
application-sized packages, you also get an idea of the user demand for such
> For the distributions that do, it might be a nightmare to adapt.
Speaking for a distribution that does a little of both, I can say with
confidence that splitting applications out of modules at packaging time is
potentially much more of a nightmare than packaging an application that comes
in its own little tarball.
Also, the potential convenience bonus for packagers of just providing 1:1
packages of the big monolithic module tarballs is pretty much blown out the
window by the constant moving about of applications and files from one module
to the other - even between maintainance releases.
> Users who build from sources would have to keep track of
> more packages,
How so? Kdelibs would be a constant requirement, third party libraries or
similar stuff users need to keep track of no matter which configure script
looks for them. I can see how finding applications to download and compile in
the first place require a little extra effort from users, but again this
could be very much mitigated by allowing extragear developers to host their
distribution tarballs on KDE.org's mirrors and/or adding them to konstruct
(if konstruct doesn't already include extragear, I don't use it so I don't
> new dependencies
> new build orders, etc.
Can't follow you here either.
Please note that I'm not at all proposing to get rid of all or even one single
KDE module. Some KDE modules have, over time, developed into a collection of
applications which are very tightly integrated and which cannot really
sensibly developed or released piecemeal. A prime example of such a module is
Other modules have not developed in that direction however and are still more
or less random collections of software of a certain theme, often with
strongly competing extragear or other non-mainline applications available
like kdeutils, kdenetwork and kdemultimedia. It's those modules where I'd use
the big broom on first.
I'm also of the (very much subjective, admittedly) opinion that kdegames and
kdeedu are probably eating away a good deal of developer resources
(especially in the translation, documentation and art department) while they
don't add much to KDE as a whole - and that they are disproportionally large.
Sure, they make KDE the leading desktop environment when it comes to the
number of games and educational software included by default, but I'm not
convinced that KDE gains terribly much of an advantage over its competitors
,_, | Michael Nottebrock | lofi at freebsd.org
(/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org
\u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
More information about the kde-core-devel