Qt 3.2 requirement

[Bernhard Reiter]

Matthias,

thanks for your post and opinion.
Let me start responding to the issues you reased in reverse order.

Naturally new versions of QT for KDE and Free Software in general
are desirable and it is good that Trolltech makes them available. 
Nobody proposed to stop testing new QT versions
and I also don't intend doing so.

Bugfixes and improvements are both important.
As you can see from my other post responding to Ralf,
I believe that the focus might slowly change over time.
KDE is becoming a mainstream product and that is a huge success.
It should be okay to try to evolutionary improve its development process
if conditions change.  Demanding "everything should run with 
everything" is unreasonable as you have already implied.

As hinted upon in my answer to Ralf, we might search
for a way to not force developers (but encourage them)
to test new QT versions and improve basic libraries
without drawbacks for the stability.
One idea would be to be more strict about separating bug-fixes
from new features.

I can fully understand your bug-fix argument,
that has not been put forward in the debate so prominently yet.
What were the reasons to not make a bug-fix only QT release
and having a new feature release available at the same time?

Note that the debate now has been drifted into more general matters.
I stressed Cornelius concern originally , because I also share it.
The first arguments coming against that view have not been very convincing.
If QT 3.2 is close to a bug-fix only release, 
it might be the right thing to switch the KDE 3.2 requirements to it.
Still the arguments for or against it should have
that drawback of forcing some developers in mind
and may that can also be improved in the future.

Bernhard

On Sunday 27 July 2003 16:43, Matthias Ettrich wrote:
> On Friday 25 July 2003 23:36, Ralf Nolden wrote:
> > On Freitag, 25. Juli 2003 22:08, Bernhard Reiter wrote:

> > > KDE libs should have their own stability criteria and not getting
> > > forced by the QT schedule. You unnecessarily force all the developers
> > > to test QT.
> >
> > Don't you realize that it's way harder to force the developers to stick
> > with an older Qt than for the others to grab and compile a newer Qt ?
> > They want to use things like QSplashScreen, see the recent other mails
> > here.
>
> With Qt 3.2.0, the feature argument is rather weak. Unless you do database
> development with the SQL module, there is little new and flashy in the
> library that you must have. Lots of small nice things, yes, but nothing you
> cannot live without. QSplashScreen, as somebody mentioned, is a rather
> simple class, KDE can easily provide its own. The community in India
> hopefully has a very different opinion about 3.2.0, but it seems not all
> western developers share this :(
>
> But even if you do not care about non-western alphabets there is another
> "but",  and that is a very big one: there are SEVERAL HUNDRED bugfixes in
> 3.2.0. Smaller and larger issues, all reported by both the Qt and the KDE
> community. Qt 3.2.0 is mostly about stability and minor improvements, and
> little about new features (btw. in NoveHrady I will talk about new features
> and improvements Trolltech develops and plans for future versions).
>
> KDE users and developers who are happy with the subset of functionality
> they are using, will most certainly vote for compatibility. And quite
> rightly so, afer all it is the job of the OTHER authors to work around
> problems in the libraries. Everything should run with evertyhing, right?
> Why not run KDE 3.2 application with Qt 1.4,  the kdesupport package from
> KDE 2 and libkdeui from KDE 3.1? Answer: Because you end up with
> stagnation, the smallest common denominator, and the most boring software
> development model imaginable for a GUI framework. And your code has around
> 5 lines of #ifdef ... #elseif ...#else ...#endif per line of logic. Look at
> the xterm sources for a shiny example. That's stuff some might do for a
> living, but hardly for fun.
>
> Bernhard, when a fix or feature gets commited to libkdecore, do you also
> raise your voice for not using the new features in KDE applications, and
> not to rely on the bugfix, because somebody might chose to run new
> applications and libraries linked against the old version? How do you think
> KDE would look like if we did that right from the start?
>
> Trolltech treats KDE as one of our most important customers. In return, KDE
> provides a fair amount of exposure and - highly important - testing. I hope
> we can maintain this partnership and that the voices that want KDE
> developers to stop test and use new Qt versions - and no longer benefit
> from the work Trolltech provides to KDE - remain a minority.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030728/37825ffe/attachment.bin>