Office/ and Utilities/ menu reorganization

[Christoph Cullmann]

On Tuesday 09 August 2005 03:31, Thiago Macieira wrote:
> Having said that...
> 
> ... I do agree we need a reorganisation. But, most importantly, we need a 
> build system that allows for easy splitting, while at the same time 
> letting developers build in one go. I'm hoping our next build system has 
> that feature. Not to mention that the generated configure scripts are 
> disproportionately large and would increase the amount of data 
> transferred.
> 
> I also agree some apps could be separated from the main KDE releases. 
> Applications in kdetoys, for instance, see so little modification that 
> releasing a new version of kdetoys just because one of them got an 
> improvement is an overkill.
> 
> So, maybe we set message & feature freezes for all apps, but still release 
> separate tarballs. Translators, documentation writers and packagers 
> wouldn't have to keep track of 150 applications.
Btw., first: Seems my "seperate apps would make i18n harder" claim was rejected by the Lauri and
as she has the experience there, sorry, won't state that again.

Me agrees that some reorganisation would be good, too.
I just would like to have a repository for apps like we have with extragear
but which is part of the normal release cycle.
These apps docs/i18n shouldn't count as showstoppers if not suffciently translated and these apps
should not ship as "The KDE Apps" but they should just ship with each release, e.g. the tarballs
are made, the freezes count for them and so on.

Let's call it "applications" or whatever, same scheme as extragear, but buildsystem  should allow to
build all or at least group wise in a row. We could even just reuse the extragear sorting, the buildsystem
would only need to take care that libs is build first. There should be rules that this apps should not depend
on compile time on each other and we would be fine, or the buildsystem would need to cope with that. 
Packagers could build the apps the want individually, like the current extragear stuff
This would help some app devs, too, as if Kate would be there, other app devs won't suffer if I break it's compile, as each app
has it's own seperate build system allowing clean standalone builds and the apps devs would like in extragear only need to
checkout their own app dir.

In addition, I think kdelibs/kdebase should be cleaned up a bit, too. I my eyes, it would be much nicer if kdelibs
really only contains the library parts and common infrastructure, and the parts there should be moved out to some
kdeparts or whatever module. kdebase should only contain the core desktop, how you ever define that, 
perhaps best disscussed on aKademy, but stuff like Kate, kdcop, ... should be moved away out of it, only the real core stuff should
stay, like plasma, kwin, ....

All in all, I think rearranging the kde packages won't be worst thing to do, really, but as mentioned before, I think most stuff should at least
be still coupled to KDE releases, as really, why should app maintainers need to take care of packaging, planning freezes and so on if that
still can go on par with KDE releases. We already have extragear for maintainers which have the time for this or for apps where the users 
need more/less often releases, like for some multimedia apps which stay bleeding edge and have bigger community.
But from my experience with Kate, the KDE release managment fits well with developing your own app, you know your dates, 
you try to work towards them, you don't have to care for creating packages, announcing & planning own timelines for i18n and co.

Now just listing what I would like to see as kde packages in KDE 4:

libs - KDE libs, perhaps with parts & slaves split out to some own parts/slaves module, not sure
base - KDE deskop itself, e.g. the core parts, KWin, Plasma, perhaps Konqueror & Konsole, whatever the kde team decides to be the desktop
apps - like extragears, with categories, but following the KDE release cycles, most kde* modules could be moved into this scheme,
perhaps just stuff which is tight coupled like kdepim and co should stay like the are and moved to pim or whatever. This should allow
packagers to just package all apps seperate, as all have like extragear their "own" buildsystem, app devs can just checkout their stuff and all that fun

This all is just my 2c, for sure ;)

(I just name it short here, no reason why libs not stays named kdelibs, no need to shuffle around in svn just for naming I guess)

cu
Christoph

-- 
Christoph Cullmann
KDE Developer, kde.org Maintainance Team
http://www.babylon2k.de, cullmann at kde.org