nolden at kde.org
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 pro-linux.de 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 kde.org 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.
> to unsubscribe from this list send an email to
> kdevelop-devel-request at kdevelop.org with the following body: unsubscribe
We're not a company, we just produce better code at less costs.
nolden at kde.org
The K Desktop Environment The KDevelop Project
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
More information about the KDevelop-devel