[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Proposal: package split
From:       Rik Hemsley <rik () kde ! org>
Date:       1999-10-03 20:46:01
[Download RAW message or body]

#if Cristian Tibirna
> First of all, KDE should become *much* smaller in the future (in what
> concerns main downloading action). KDELibs and KDEBase (carefully
> reorganized) should come in a very easy-to-install form and then an
> organizing application should be offered which will help the user to
> install all supplementary packages he needs from an easy to use interface,
> with connections to both local and remote filesystems.

Agreed. Too often I get Linux users saying to me '_HOW_ much do I need
to download !?!'. Of course, they don't need the lot for a usable system,
but there's no need for such huge packages when you only want one out
of the package (e.g. I only use kppp out of kdenetwork).

> The strongest arguments against your proposal are the kbiff/korn and the
> kedit/kwrite examples. These pairs of apps are offering generally similar
> functions but fundamentally different functionalities. Who are we to shove
> down the people our subjective choice in these cases. If korn is dropped
> from kdenetwork I and many others will be very upset. If kbiff is dropped,
> Kurt and many more will be very upset. And this is right on behalf of both
> groups.

Agreed. You can't go around upsetting developers. I would understand if
I was told to clear Empath out of CVS, but I've got a thick skin. You'd
lose other developers though by offending them.

What I'd suggest is to mention to the concerned parties that a merge might
be in order. I see no reason the kbiff can't subsume korn, which AFAICT only
has one extra feature.

As for kwrite/kedit, they are again so similar that a merge must be easy.
If kwrite had the features of EMACS, it would be worth keeping them apart,
as loading time, binary size, etc, would be a factor.

As a counter-argument to that, I believe that kwrite will become more powerful
as it is used more in KDevelop. If that is the case, at some point it may
be prudent to split the two, so there's an editor that loads fast and takes
little memory. There's a reason I don't use the vi-emulation modes of Emacs,
and stick with Vim :)

Cheers,
Rik

[prev in list] [next in list] [prev in thread] [next in thread]