RFC: remove qt-copy

[Lubos Lunak]

On Wednesday 27 of May 2009, Thiago Macieira wrote:
> Lubos Lunak wrote:
> >On Wednesday 27 of May 2009, Thiago Macieira wrote:
> >> For patches that got rejected, study case-by-case (example is 0180).
> >
> > And what? I suggest having a look at qt-copy for Qt3, as that one is
> > much more interesting.
>
> And study case-by-case what to do. Any rejected patch should explain why
> it was rejected. For example, Ben Reed's patch that would break
> compatibility on plugins was rejected. So he concluded that it shouldn't
> be enabled. I don't have any examples of patches that were rejected and
> then dropped because of it, but I'm sure this has happened too.
>
> > #0048 is a really ugly hack and was meant just as a temporary solution.
> > Two years after that, Qt changelog mentions a fix for the problem. A
> > very non-trivial problem to solve I might add.
>
> 0048 and 0036 are binary incompatible because they export new symbols.
> Besides, you yourself wrote on 0048 that it was a crude hack.

 It is not binary incompatible. It was used only by Klipper and the code was 
written in a way so that it would work with any Qt setup. And it may be a 
crude hack, but it was useful, and I'll do the same again if there will be 
the need, regardless of what upstream Qt might think about it. That's why I 
disagree with the only-approved-for-merge rule.

> And 0036 is much, much worse and it's the one I was thinking of when I said
> that most distros ship it now, despite breaking BC with the official Qt.

 A good reason to be able to easily see all patches separately and not just 
have them all lumped together.

> When I checked Qt 3's patches (that was in 2006, close to the 3.3.5 or
> 3.3.6 release), what happened was that most patches were unknown to the
> trolls. I did this exercise again once or twice for Qt 4 and again I found
> many patches that had never been submitted upstream.

 That's not really relevant to my point. I was saying that there will be 
patches that upstream Qt will not merge for whatever reason and that we need 
to be able to keep them somewhere. I'm pretty sure that most of my patches 
that didn't make it had been submitted.

> And that's why kde-qt.git is there. Its purpose is to hold the version of
> Qt that is recommended by KDE, including patches created by KDE and
> important backported fixes from Qt.

 That's slightly different from reviewed-and-approved-for-merge though, 
assuming I understood correctly that you meant by-Qt-Software here. If it was 
by-us, then I'm ok with that.

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http://www.suse.cz