Office/ and Utilities/ menu reorganization

[Michael Nottebrock]

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.

> packaging

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 
above.

> and annoucement.

Application maintainers already have to provide changelog entries themselves 
and KDE.org already features application announcements from kde-apps.org on 
its frontpage.

> The translators and documentation writers would have to keep track of
> yet-another-release-schedule.

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 
documentation writers.

> 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 
reduced.

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 
packages.

> 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 
know).

> new dependencies

See above.

> 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 
kdepim.

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 
through that.

-- 
   ,_,   | 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
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050808/7a0e71f0/attachment.sig>