Office/ and Utilities/ menu reorganization
matze at stud.fbi.fh-darmstadt.de
Mon Aug 8 20:29:56 BST 2005
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
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
> 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.)
More information about the kde-core-devel