Office/ and Utilities/ menu reorganization

[Matthias Welwarsky]

On Tuesday 09 August 2005 00:44, Christoph Cullmann wrote:
> 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? ....

OK, but qt4/kde4 is kind of a 'dramatic' situation. If you really have to work 
constantly on let's say kdf because of perpetual kdelibs changes, I'd say KDE 
has a real problem. As for the maintainer wanting or not to port an 
application, that should be left to him.

Let's face it, what we're talking about is abandonware. If there is a 
maintainer for an app, all this is a non-issue, because someone is actively 
taking care of it. It's not like applications get fixed magically if they 
happen to be inside a module. Someone is doing it.

> > 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?

If a maintainer exists, this is not a problem. If they've become abandoned, 
they will eventually rot away. And as I said before: if an application breaks 
because of a kdelibs change, then this has to be fixed in kdelibs, not in the 
application.

> > 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?

The stuff in kdebase (kicker, konqueror, etc) usually keeps up with the pace, 
but it should not really be mandatory. And the very reason why extragear is a 
success (IMHO) is because there is a demand for breaking out of the cycle. If 
you look at amarok, k3b, digiKam, these are real assets of KDE.

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

Again, users are not going to change distributions for the sake of KDE. Let's 
just accept that distributors are doing _us_ a favour to package KDE. We 
should make it more convenient for them to create a "a pleasent KDE 
experience" for our users (god, I got infected by a marketing speech virus).

It's been said already that packagers are apparently more comfortable with 
separate tarballs. It's actually easier for them from a dependency point of 
view. Take a look at the kdegraphics module: each application in there has 
its own set of external dependencies, so packaging the whole module (which is 
easiest) forces you to install a slew of additional libraries. It's way more 
transparent to maintain the external dependencies for each application than 
for the whole module. Plus, the user get's a better chance to have a lean, 
mean linux system with less unwanted stuff installed.

Let's say I just want kuickshow. With the current suse packaging, I have no 
chance to install it alone, its packaged together with kiconedit, kolourpaint 
and kview. The module itself even contains a provray model editor! What's the 
chance of me wanting to have that installed? Or take kcolorchooser. I'm sure 
it's a nice tool for a web developer, but for 95% of the people it just 
clutters the start menu, and who actually has a use for kruler?

>
> cu
> Christoph

-- 
From the 'Handbook of Corporate Slang':

- to protect prior investment (phrase):
    describes the inability to revert a wrong decision made
    in the past, expresses willingness of throwing 
    good money after bad. (q.v. Fiorina, C.)