3rd June 2005 by Derek Kite

This Week...

Kexi supports CSV import. kttsd adds support for Cepstral voices. Kopete add webcam receiving support for yahoo. Kopete implements global identity for all the IM services. KTorrent add search capability. Kopete support for Skype is in progress. Datakiosk adds prompts for sql queries and search.
The work on KDE4 continues. Many of the base applications can be run, although not reliably. The strategy is to get everything building and running, then start to sort out the remaining problems. While this is happening, bugfixes and improvements continue to be made to the KDE3 codebase in preparation for KDE 3.5. These fixes need to be ported to the KDE4 development tree. The porting from trunk will become more and more difficult as the two trees diverge. Applications trying to port face libraries that are a moving target. Obviously the situation is somewhat confusing and could become unmanageable. Stephan Kulow started a thread on kde-core-devel to elicit comments on how to best approach this. [1]
As originally announced I would like to have trunk based on Qt4 really soon now. For this I would like to branch off trunk this friday (and use the time till then to do an initial port of some more modules).

The translations were unaffected and would happen from the 3.5 branch. The 3.5 branch would still be an active development branch, but every change done there has to be done also in trunk. The actual schedule on merging might vary from app to app or even module to module, but that should be the goal. We can even make a public list of all revisions happened to 3.5 branch and strike off forward ports through a commit keyword (or some similiar mechanism).

But I think this needs to be done even before Qt4 is released. And it's no longer a completly uncertain adventure, but we know pretty well by now how much porting effort is behind Qt4 - but what we do not know is how well it runs. Getting konqueror to compile was done in pretty short time, but getting it to work for daily usage will still take a good while and we should as project should have good overview over it.

Everyone is free to stay and develop for KDE 3.5 as long as he feels like it, but everyone should be aware that the development for it needs to be ported to KDE4 without too much major pain or you're just asking for frustration.
Some of the issues were elaborated upon as the discussion continued. Stephan's goals is that [2]
KDE4 is the main target, KDE 3.5 development is defined as backport
and possibly [3]
OK, so how about dropping the idea of KDE 3.5 then? At the Akademy discussion KDE 3.5 was always discussed as "rest release". We really can't afford having KDE 4 be released in two years from now. And to get that done, we need all manpower we can get.
Then further [4]
Take it as it is, but KDE 3.5 _is_ a step child and we can continue this "we need a KDE 3.X (where X is larger than the previous released)" discussion for years now. It just won't help us. We started with KDE 4 development - given fact. This means KDE 3.5 sees less development than any other KDE3 release - given fact. Now we have to make sure to find the balance between a) getting KDE 3.5 out at all and b) getting KDE 4 out in an overseeable future.
These sometimes radical proposals brought forth many opinions. (Stephan Kulow acknowledged that he was being somewhat outrageous on purpose [4]. When herding cats an easy way to get everyone's attention is to get everyone mad at you.) The KDEPIM developers came to a consensus during their recent meeting on a future roadmap. [5] Cornelius Schumacher wrote in part:
The basic assumption of the roadmap is that we won't be able to do feature work in two different branches, while porting one branch to Qt 4, because we don't have the resources to cope with the inevitable merging hell which would result from this. So we propose to concentrate on the 3.5 release and start Qt 4 porting and KDE 4 feature work when 3.5 is basically done.
That means that the KDEPIM porting effort will begin in August after the release of KDE 3.5. Many KDEPIM developers, including Thomas Zander [6] , Martijn Klingens [7] and Ingo Kloecker [8] asked that trunk/KDE/kdepim be read-only to prevent a confusing mess. Their reasoning is that with the current manpower it is reasonable to concentrate development efforts on one tree. Once the 3.5 features are complete, then KDE 4 development will begin in earnest.
Other developers stated their planned schedules. Aaron J. Seigo wrote [9]:
i noticed people have touched kde4/kdebase/kicker which i really wish they hadn't. if you had to run a KDE3 linked kicker for another month or two i doubt it would've been a cause of great consternation, but making changes in kicker right now really doesn't mesh with the schedule i've set out, much as with the kdepim people
and with some suggestions on how to go about this: [10]
i think there is a compromise to be had in realizing that applications will start porting at different stages according to their priorities and schedules. so there will be some coordination needed here between "core" and "KDE applications". i think this also really helps to self-define the lines between "KDE core" and "KDE applications"

in any case, i'd recommend that "small apps" such as kdeutils, kdetoys, kdeadmin, etc. be brought over immediately, bar none. ditto with kdelibs/kdebase (yes, in spite of me dragging my heels for up to another 4 weeks with kicker ;) ...

kdemm probably will want to come over sooner than later too due to the massive changes they will need, but that's something best expressed by the kdemm developers.

as for the rest, i'd make it clear to them the issues and let them schedule their devel switch as it works for them. we should respect those wishes and not port the code on them in the meantime. many of these projects rarely or never touch kdelibs/base anyways and so for them following a moving target until it settles down a wee bit may not be worth it.
Stephan then responded: [11]
For now I merge over changes done in trunk and it's still pretty easy to merge as we haven't done too many changes that can't be easily reverted and redone (calling qt3to4 and get it to compile). And as I said: if your feature freeze is end of june, that's fine. You just switch working to 3.5 branch and leave trunk alone for the month. If you're done, you port it over in one go - either reusing or overwriting the changes done in trunk so far.

I'm also fine with whole of kdepim joining trunk development only in august. I even suggest we remove kdepim from trunk then and copy it back into trunk later. But that doesn't work for kicker. We really need a gradually ported KDE4 to test changes done to the framework. And we have to make sure we're not loosing overview - and if all KDE 3.5 development is going to be merged by me, we're going to loose overview. So I want a change in policy who is responsible for merging KDE 3.5 development into the then main development branch - I don't want to dictate a policy on when this needs to be done and not even how.


Commits 2531 by 202 developers, 60862 lines modified, 1529 new files
Open Bugs 8988
Open Wishes 8402
Bugs Opened 321 in the last 7 days
Bugs Closed 325 in the last 7 days

Commit Summary

Module Commits
Lines Developer Commits
Adriaan de Groot
David Faure
Laurent Montel
Albert Astals Cid
John Tapsell
Gilles Caulier
Stephan Binner
Rob Buis
Stephan Kulow
George Staikos

Internationalization (i18n) Status

Language Percentage Complete
British English (en_GB)
Swedish (sv)
Danish (da)
French (fr)
Portuguese (pt)
Spanish (es)
Estonian (et)
Dutch (nl)
Serbian (sr)
Brazilian Portuguese (pt_BR)

Bug Killers

Person Bugs Closed
Tobias Koenig
Sebastian Trueg
Matt Douhan
Stanislav Visnovsky
Tommi Tervo
Thiago Macieira
Stephan Kulow
Matt Rogers
Dirk Mueller
Jakob Schröter

No commits found