--Boundary-02=_VLaI/RAAVS2pgTd
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Freitag, 25. Juli 2003 22:08, Bernhard Reiter wrote:
> On Friday 25 July 2003 19:47, Ralf Nolden wrote:
> > On Freitag, 25. Juli 2003 14:32, Bernhard Reiter wrote:
> > > In my experience your argument leads a huge block
> > > consisting of QT /kdelibs /application that is changed altogether,
> > > leading to a lower quality of the overall system
> > >
> > > When trying to fix bugs in currently used KDE versions,
> > > I've frequently been pointed to try the "latest" and "greatest"
> > > version from CVS on the whole block because that was what
> > > developers are using. It leads to problems which were not present
> > > before and I did not get to the point in actually fixing the
> > > application bug. It is not a weak argument, because stablising KDE
> > > application code towards a certainly level is getting very cost
> > > intensive.
> >
> > If you use qt-copy that's your fault :-)
>
> It is not a good process to force the stability and schedule of QT
> onto KDE nor the kdelibs schedule on the applications.
>
> >  You should take the official
> > release version from Trolltech and the beta versions of that version ha=
ve
> > been tested with KDE plus the results folded back into Qt.
>
> That didn't help way back then.
>
> > You won't and can't prevent developers to use the newest library and so
> > over time the whole thing becomes a restriction to say we only use
> > qt-3.1.x because qt-3.2 may have the classes you want to use. Also, for
> > those who want to test indian languages they *need* to take Qt 3.2. It
> > *will* be a requirement. The more it is tested, the better, because
> > within the timeframe of the KDE 3.2 release a bugfix release of Qt 3.2
> > will be available for sure, so we can have KDE 3.2 use a *stable* and
> > *well-tested* Qt 3.2.x
>
> I wouldn't fully agree with this.
> 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 wit=
h=20
an older Qt than for the others to grab and compile a newer Qt ? They want =
to=20
use things like QSplashScreen, see the recent other mails here.

Ralf

=2D-=20
We're not a company, we just produce better code at less costs.
=2D-------------------------------------------------------------------
Ralf Nolden
nolden@kde.org

The K Desktop Environment       The KDevelop Project
http://www.kde.org              http://www.kdevelop.org

--Boundary-02=_VLaI/RAAVS2pgTd
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA/IaLVu0nKi+w1Ky8RAo84AKC6SfxPzeJCxFJP8q5GuHnDwSkV2wCfY5ob
BuW/wl3+8OlqnBCX+MBAWqo=
=imtN
-----END PGP SIGNATURE-----

--Boundary-02=_VLaI/RAAVS2pgTd--