Office/ and Utilities/ menu reorganization

[Thiago Macieira]

Michael Nottebrock wrote:
>I don't buy any of that. Qt and Kdelibs are binary compatible over long
>periods of time, making a tarball is a matter of five minutes maximum

I'm sorry, but have you tried?

I tried making a release for Kopete after the MSN server change. I was 
faced with two choices:

1) download the existing tarballs, apply a patch and tar up again

2) try to make the tarballs from SVN

I chose the latter. Maybe it wasn't the best choice, because it took me 
several hours to:
- download the sources from Subversion
- download all translations for kopete
- download all documentation for kopete (granted, there are not many)
- package up
- then do a test compile to make sure everything was in order

The test compile alone takes over half an hour.

Half-way through, I gave up getting the translations and doc for the 0.9.x 
release (the one in KDE/3.3/kdenetwork). And even with all the care that 
I took, the packages were broken and Matt had to create new packages with 
a new release number.

It most likely is a lot easier for a small app in extragear. But you are 
asking to split a couple of rather large applications from the codebase, 
for developers who have never made a single release. Not to mention that 
configure tests are spread over the whole module, so the configure.in.in 
scripts would have to be adapted.

Another point is that some small apps make no sense being packaged 
separately. Users would never find out they exist.

>... and it would mean that users only get kile, kdvi, kghostview and
> kpdf in the end - but not a bunch of very much TeX-unrelated,
> gratuitous stuff like kpovmodeller, kfax, kruler, kview, the X11 gamma
> correction kcm module ...

You miss the point. Instead of tracking one dependency, the user and the 
packager now have to track three or more. Add the complexity of versions:

(fictitious data)
kile 2.0 requires kpdf 1.0, kghostview 0.25 and kdvi 1.5
kile 2.0.1 requires kpdf 1.0.1 to fix a regression
kile 2.1 requires kpdf 1.0.1, kghostview 0.27 and kdvi 1.6
etc.

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.

Please note that kdelibs would grow by a substantial amount.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

3. Ac seo woruld wearð geborod, swá se Scieppend cwæð "Gewurde Unix" and 
wundor fremede and him "Unix" genemned, þæt is se rihtendgesamnung.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050808/766cc826/attachment.sig>