Ralf Nolden nolden at
Fri Aug 10 11:21:08 UTC 2001

On Friday, 10. August 2001 13:10, you wrote:

> Yes, but you have forgotten the people who want the test Gideon. Granted
> there is nothing to test in Gideon so that the only users of Gideon will be
> developers the next months. And those developers are usually "armed" with
> the latest Qt and KDE libs.
Erm, what about other KDE programs that are only supposed to be used by 
regular users ? In fact, we have a far larger user base than e.g. KMail. And 
if you look at *that* sourcecode, you see that there's trouble ahead, so 
we'll be kind of lucky anyway. Which users do you want to test things ? 
Please have a look at or other sites. Most developers who want 
to test and are willing to provide usable feedback for us are using HEAD over 
anonymous CVS, and if we step back, we decouple the wagon from the train. The 
end of the story is the train moves on but the wagon stops.
> But as Sandy said: We might get into serious troubles with buggy KDE libs
> and other things. On my opinion we should wait until there exists something
> stable. Speaking of technical things (the new component model) and APIs. I
> think we do nothing wrong if we wait. But many things could go wrong if
> don't wait.
KDElibs are stable. They are supposed to be moved to Qt 3 in 3 weeks, the 
last days even Qt 3 by rsync doesn't show any changes, so Qt 3 is stable as 
well (which is why we're moving KDE to that anyway). So I don't count very 
much on that problem and *if* there are problems, you can have me as your 
target to flame at :). Don't forget to cc mueller at because he is the 
release dude for KDE 3 and he has to take care for our good as well :) What 
we loose in respect to the API is that we don't have anyone who can provide 
for example Qt-only plugins. You just prevent that with sticking to KDE 2.2 
and Qt 2.3.1. Those developers that are willing to test would also come up 
with simple ideas where even a Qt plugin would last instead of a full-blown 
KDevelop plugin etc.etc. Waiting causes more problems that it takes on effort 
to keep up with the changes to be expected on kdelibs.


> Bye,
> 	Victor
> -
> to unsubscribe from this list send an email to
> kdevelop-devel-request at with the following body: unsubscribe
> »your-email-address«

We're not a company, we just produce better code at less costs.
Ralf Nolden
nolden at

The K Desktop Environment	The KDevelop Project

to unsubscribe from this list send an email to kdevelop-devel-request at with the following body:
unsubscribe »your-email-address«

More information about the KDevelop-devel mailing list