18th February 2005 by Derek Kite

This Week...

Kttsd adds support for Italian Festival voices. Umbrello improves import from ArtisanSW, Visio, ArgoUML, Fujaba and NSUML. KSpread has a new insert calendar plugin. Konqueror loses its Cut/Copy/Paste buttons. KDE begins move to Subversion and discusses future roadmap.
We are currently in a string and feature freeze till February 22, 2005. Shortly after that we will have a release. See kde-3.4-release-plan.html
Eventually KDE will be moving to Subversion for source code management. A Subversion repository has been set up at svn.kde.org, and is open for testing. Developers can try checking out, committing, creating branches, moving stuff around. Remember that any commits need to be made to the cvs repository.

For a KDE specific HOWTO, see
http://wiki.kde.org/tiki-index.php?page=KDE+Subversion+HOWTO.

Read Stephan Kulow's announcement at
http://lists.kde.org/?l=kde-core-devel&m=110873178005143&w=2.

And further discussion of some issues with Subversion
http://lists.kde.org/?l=kde-core-devel&m=110863143108116&w=2
A rather important post from Stephan Kulow showed up on kde-core-devel entitled Future of KDE Development. Stephan lays out the challenges coming this year: http://lists.kde.org/?l=kde-core-devel&m=110839367905112&w=2
  • Change to subversion
  • Qt4 port
  • Windows port
  • Build system change (as related to the above and more)
  • Switch to standard gettext
  • DCOP changes (DBUS was discussed)
  • Change of soundsystem layer
  • Further cleanup of our API (there are already tons of KDE4 comments)
The question is how to accomplish all of that, all the while putting out a release from time to time. Stephan continues:
This all sounds like a lot and it surely is. Still no-one would like to have KDE4 in late 2006, but the earliest possible. And even if there is no stable release for users, we would like to have a version that works good enough for our own daily use (at least some do, some prefer to run Xnest :)

And on top of that, not everyone wants to ditch the KDE3 code base and start working on KDE4 right away, but would prefer a KDE 3.5 application release, which would delay KDE4 even more due to split of man power.
Many of the changes are not time critical, some are. So Stephan proposed a roadmap:
Anyway, let me draft a roadmap:
  • KDE 3.4 is released
  • we migrate to subversion (this will require some downtime of development per module that we will interleave)
  • we create a bunch of branches:
    • KDE_3_5_BRANCH (or /branches/KDE/3.5 :) for a future KDE 3.5 release. When it's clear that development in there stops as people are satisfied/bored with it and rather spent time with Qt4, we make a release on short notice (e.g. two months after we agree to release) - latest christmas 2005.
    • new_build_system_branch - as long as nothing compiles, I would like to have it branched. I guess you agree.
    • Qt4_branch for modules beside kdelibs. HEAD of kdelibs will be Qt4, but all other modules should branch off Qt4 porting as long as it's not settled.
    • DBUS_branch/noarts_branch/whatever. As long as it's in early development, it should stay away from HEAD. This way we might have an at least half way working HEAD at all times.
  • We remember a nice rule of the past: incompatible changes in HEAD (i.e. experimental branch merges) are only done between monday and wednesday. With subversion we're supposed to have much better control over branches, so we should make use of them whenever we can.
  • We will release an alpha1 whenever one of the things in my list is finished and the sources compile. We do that every 6 weeks at least after the first alpha1 till we reach a state where we can claim we're done through the basics and then we write down when to feature freeze, etc. This is all way too early to say now.
So I can very well imagine we finish the initial Qt4 port around the same time KDE 3.5 is due, so it might be a perfect match.
This of course spawned quite a bit of discussion. There is a recognition that regular releases are important. The artwork, documentation and HIG people have things they want to implement, and a release in 18 months or so would create problems, especially if there isn't a usable cvs (or svn) build due to the major changes taking place. Cornelius Schumacher makes another important point:
Doing kdelibs 3 based feature development in parallel to Qt 4 porting and kdelibs 4 development sounds like a nightmare, because of the following reasons:
  • Lack of resources. I doubt that there will be many people being able to work on a kdelibs 3 branch as well as on a kdelibs 4 based branch. For me personally I know for sure that I won't be able to do this.
  • Merging hell. Merging Qt 3 based features into code already ported to Qt 4 will be, well, challenging. Renamed classes and functions, Qt API changes and new concepts like the model-view classes or the new iterators will make this very difficult, error-prone and labor-intensive.
  • Library development can't be done theoretically. We need the applications using the libraries for making the right decisions about the API and the implementation of the libs, we need them as test cases and we need the modules participating in the libs development, so that code that belongs to the libs, but now is in the modules can be integrated into the libs.
An additional problem I see is that Qt 4 isn't finished yet. The Trolltech roadmap says that Qt 4 won't be released before June, that's still four months ahead. I have tried the previews and the beta and my experience was that it's nice for testing and playing around, but nothing I would like to use for serious development (which is quite natural for prewies and beta releases).

So what about the following proposal: Next release after 3.4 will be 3.5. We use the four months till the Qt 4 release for implementing outstanding features and usability improvements, integrating new artwork from kde-look contests, improving documentation, completing translations, moving to subversion, experimenting with a new build system, but don't do any Qt 4 porting yet.

The day Trolltech releases the final version of Qt 4.0 we branch and freeze CVS (or rather subversion then) for the 3.5 release and start porting the HEAD branch (libraries and modules) to Qt4. Then we proceed with the alpha release scheme Stephan proposed until we have a KDE 4.

Not doing 3.5 and 4.0 development in parallel avoids the problems I mentioned above and has the additional advantage that the Qt 4 port could be done as concerted effort by all developers, so that we quickly get to a state where everything compiles and is usable for development again. Maybe something like a "porting meeting" could be held to do this in the most efficient way. Maybe also Trolltech could help with this, the Qt developers won't have anything to do anymore after the Qt 4 release, after all ;-)
Stephan responded:
No, we need to do major Qt4 porting _before_ the API is final. Been there, done that with Qt2 and Qt3 - you say yourself that you need applications using the library to design a good library and say two paragraphs later thatwe shouldn't use Qt4 before it's done. Don't you see the irony yourself?

No one says we will do any kind of kdelibs features beside artwork for KDE 3.5 and yes, KDE 3.5 won't be the KDE release we put the most effort into. But that's fine.
Aaron Seigo made an interesting suggestion:
i'd really like to see that _any_ user-facing GUI that goes into the "KDE desktop" (konqueror, kicker, kdesktop, kwin, kcontrol; hrm.. what else?) get a UI review BEFORE being ok'd for inclusion in release. this would happen before, on or around the time of committing it. the review would include checking for HIG compliance and, time and resources permitting, a review by another KDE contributor for usability and accessibility concerns.

i'd also like to propose that we have another freeze period in the release. after feature freeze but before string and documentation freezes, it would be very nice to have a UI review freeze.

this release Waldo has been spearheading a review of kcontrol and i've been doing clean ups in konqueror, kfiledialog and kontact. these are made more difficult by the string freeze and are harder to do before the feature freeze. by having a recognized period of time for this it would also draw more attention and effort towards getting our GUIs clean and consistent.
This discussion spawned other threads, such as http://lists.kde.org/?l=kde-core-devel&m=110839698932029&w=2 titled Build system (was Re: Future of KDE Development). And http://lists.kde.org/?l=kde-core-devel&m=110848973326561&w=2 titled HIG (Future of KDE Development).

Statistics

Commits 3277 by 232 developers, 268177 lines modified, 1252 new files
Open Bugs 7829
Open Wishes 7223
Bugs Opened 324 in the last 7 days
Bugs Closed 381 in the last 7 days

Commit Summary

Module Commits
kde-i18n
1658
 
kdeextragear-1
190
 
kdelibs
179
 
www
168
 
kdebase
134
 
kdenonbeta
132
 
kdepim
123
 
koffice
90
 
kdeextragear-2
84
 
kdeextragear-3
68
 
Lines Developer Commits
10558
 
Pedro Morais
160
 
2040
 
Thierry Vignaud
126
 
862
 
Adriaan de Groot
123
 
25515
 
Stephan Johach
113
 
13097
 
Matthieu Robin
98
 
26894
 
Erik Kj
92
 
10751
 
Stefan Asserhäll
88
 
1572
 
Max Howell
73
 
3545
 
David Faure
73
 
11034
 
Federico Zenith
64
 

Internationalization (i18n) Status

Language Percentage Complete
Portuguese (pt)
100%
 
Swedish (sv)
99.97%
 
British English (en_GB)
99.61%
 
French (fr)
97.68%
 
Danish (da)
97.68%
 
Dutch (nl)
95.89%
 
Estonian (et)
95.68%
 
Italian (it)
93.69%
 
Brazilian Portuguese (pt_BR)
89.86%
 
Spanish (es)
88.72%
 

Bug Killers

Person Bugs Closed
Reinhold Kainhofer
39
 
Aaron J. Seigo
34
 
Till Adam
33
 
Thiago Macieira
32
 
Stephan Binner
23
 
Andras Mantia
21
 
Anders Lund
19
 
Tom Albers
17
 
Matt Rogers
14
 
Leo Savernik
14
 

No commits found