Office/ and Utilities/ menu reorganization

[Matthias Welwarsky]

On Monday 08 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,
> packaging and annoucement.
>
> The translators and documentation writers would have to keep track of
> yet-another-release-schedule.

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.

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.

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.

> The packagers would have to keep track of new releases, more dependencies
> and more build scripts to maintain.
>
> For a user of a distribution/OS that doesn't split packages, that's more
> packages to install and keep track of. For the distributions that do, it
> might be a nightmare to adapt.

It won't. It's not like a few more build scripts would make any difference for 
a mature distribution, especially if the scripts are just copy&paste jobs. Of 
course the transition is somewhat awkward, but once you've done it, it's not 
more work than maintaining the apps in the same module - either your 
buildsystem picks up changes automatically or you have to do it by hand, same 
work in both cases.

Regarding the dependencies, it's not like all the modules are self contained 
and satisfy all their dependencies in themselves, that task does not become 
much more complicated. For some modules it would, of course, for example pim, 
but nobody wants to just willy-nilly rip modules apart just for the sake of 
it.

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


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