RFC: remove qt-copy

[Sune Vuorela]

On 2009-05-25, Aaron J. Seigo <aseigo at kde.org> wrote:
> --nextPart1663294.0fHKoBbkBR
> Content-Type: Text/Plain;
>   charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
>
> On Monday 25 May 2009, Sune Vuorela wrote:
>> The current way of doing things for me (in debian) is to take the
>> released qt tarballs and read over the patches dir of qt-copy and
>> delicately pick the ones I think is relevant and understandable (these
>> factors is also influenced by commiter and names in the patch)
>
> erf ... are we sure that having packagers decide which patches are best is =
> a=20
> better mechanism than having this done upstream in KDE? that sounds like a=
>=20
> great way to have various functionally incompatible versions of Qt out ther=
> e=20
> with the reasons for those differences depending on the understanding and=20
> motivation of the packager.

You already have that - various functionality differences - and packagers also 
randomly patches kde and whatever else they ship. Packagers also apply patches 
to qt that aren't part of qt-copy. Welcome to open source.

The packagers are first in line for issues in the distribution. Why
shouldn't they have the last word in what they ship?

If it is hard to figure out why a specific patch is needed, then you
(plural) haven't done the work of documenting it good enough.

> as a software developer, that runs chills (and not the good sort) down my=20
> spine.

As any other patch we apply, we of course study it and considers wether
we want to apply it. 
Currently, I think we have picked all qt-copy
patches that aren't marked as "windows only", that was available last we
updated the Qt in Debian.

We do also look at the patches to see how important it is to get
something out now or if it can wait until some later time.
A fix for a common crash in kmail might trigger us to update almost
immediately, whereas a rendering glitch in toolbars under special
conditions might wait to next expected update.

For details, look at 
http://patch-tracking.debian.net/package/qt4-x11/4.5.1-2
And we are at least carrying one qt-copy patch that I think we shouldn't
have, but now we would just have to live with it.

> i'd much, much rather see a "you pick either qt or kde-qt" world. two versi=
> ons=20
> of Qt is already too many if you ask me and hopefully in this brave new wor=
> ld=20
> kde-qt will simply become a staging ground for the changes KDE needs in Qt=
>=20
> itself and everyone just packages Qt directly.

Is kde-qt going to have regular releases? OR do you expect packages to
do random snapshots at random times? What happens the day someone
accidentally pushes some BIC change to kde-qt at the time the
distributions choose to snapshot it?

Who watches over kde-qt (or qt-copy?)

/Sune