14th November 2003 by Derek Kite

This Week...

A deeper freeze is called for in preparation for release. Kexi, a graphical database application now has gui and non-gui parts. Many bug fixes, including searching and sorting fixes in Juk, topmenu fixes in KWin, CSS and Javascript fixes in Konqueror.
In my more curmudgeonly moments (daily it seems) I wonder about this release stuff. There are applications that are not finished, and could use a few features. Obviously, I am not the only one. Stephan Kulow posted a note to kde-cvs about the feature freeze:
Most everyone heeded the call. The number of non-bug fixes has dropped. A few projects have started development branches, ie. Quanta and Kopete. The whole thing is coming together quite nicely. One project that begs for more time before release is Kontact. What will be in 3.2 is unfinished, lacking important functionality. But to meet a release schedule, and have a working program, albeit incomplete, requires compromise. One such compromise didn't sit well with one of the Kontact developers. Daniel Molkentin committed some code with this comment:
Preload certain plugins entirely. Currently only kmail does this.
Cornelius Schumacher asked:
Does that mean that the KMail part is now always loaded on startup of Kontact?
Daniel Molkentin responded, explaining why:
That's what I discussed with Ingo and Till, and I see no other way around that. Wouldn't it look odd to you if you start you fully integrated PIM suite where you told the kmail part to fetch mails and it won't, because it's not loaded? Upps. Until KMail has not been properly splitted into libs / DCOP services. I see no better way. Otherwise we face a big usability problem and some bugs cannot be solved either.
Cornelius Schumacher wrote
So we are finally back to the monolithic monster app we promised not to write?
Daniel Molkentin explained why this was being done.
Nope, we are facing a temporary workaround. And if you read my previous post carefully, there are a lot more arguments than just the summary to do this. Most important the fact that it will not retrieve mails automatically in the background otherwise.
and further...
Yes, _should_. And herein lies the problem. I hope we can solve this for the after-3.2-release, but the KMail guys decided to delay that, and we have to cope with that now.
Zack Rusin added to the conversation:
You make it sound like we've made a silly choice. Split of the core is not something we could do without breaking stuff. It seems people view it as a three step operation:
  1. split core,
  2. make kmail awesome,
  3. go get cookies.
It's not like KMail 3.2 is lacking in the new features department. It will come, just wait a bit.
So, there is much work yet to do. And, there is a release to get out. Two sometimes incompatible demands that require compromise and patience.
A year ago, KDE3.1 was at the release candidate stage with RC2 released, and the focus was on i18n and khtml bugs. Some things don't change.

Statistics

Commits 1950 by 195 developers, 332330 lines modified, 753 new files
Open Bugs 4449
Open Wishes 4759
Bugs Opened 425 in the last 7 days
Bugs Closed 579 in the last 7 days

Commit Summary

Module Commits
kde-i18n
924
 
kdenonbeta
243
 
kdelibs
111
 
kdebase
89
 
kdevelop
74
 
kdepim
73
 
koffice
63
 
kdeextragear-2
55
 
kdenetwork
52
 
quanta
49
 
Lines Developer Commits
7699
 
 Matthieu Robin
112
 
0
 
 Marcus Camen
70
 
9607
 
 Erik Kj
68
 
8473
 
 Stefan Asserhäll
66
 
5188
 
 thd
64
 
917
 
 Unai Garro
60
 
8380
 
 Stephan Johach
51
 
5225
 
 Pedro Morais
49
 
389
 
 Laurent Montel
46
 
1049
 
 Stanislav Karchebny
40
 

Internationalization (i18n) Status

Language Percentage Complete
Swedish (sv)
100%
 
British English (en_GB)
99.98%
 
Danish (da)
99.88%
 
Hungarian (hu)
99.61%
 
Spanish (es)
98.39%
 
Portuguese (pt)
96.69%
 
Serbian (sr)
96.62%
 
Italian (it)
96.43%
 
Brazilian Portuguese (pt_BR)
95.27%
 
German (de)
94.42%
 

Bug Killers

No commits found

Thanks for reading the KDE Commit-Digest!