RFC: remove qt-copy

[Thiago Macieira]

Lubos Lunak wrote:
>On Wednesday 27 of May 2009, Thiago Macieira wrote:
>> Benjamin Meyer wrote:
>> >I would even go so far as to
>> >say that no patch should be allowed in kde's Qt repo unless it has
>> >been submitted to be merged.
>>
>> I would go even further: the patch should have been reviewed and
>> approved for merge, hopefully already merged into the Qt mainline. Qt
>> Software is committing itself to reviewing patches quickly.
>
> Since when?

Two weeks ago. I'm talking about merge requests, not bug reports. Merge 
requests go directly to developers. Bug reports are triaged by the support 
team, which is completely understaffed right now.

In the case of the merge request, the burden of writing a testcase is on 
the sender, if a testcase is possible, and ensuring that it's not breaking 
other existing tests.

> As an exception, I'm not saying here that qt-bugs sucks, but I'm merely
>pointing out the fact that Qt Software still can't keep up with
> everything we throw at them, and it's a question if they realistically
> ever can.

I understand. But I was talking about what we should strive for. Until 
we're there, there will be temporary measures.

>> 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. 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.

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.

If it's not submitted, it'll never be in Qt. So let's share the blame 
here,

> And there are other patches that have never been accepted, be it the
> usual sloppiness of qt-bugs in the past or any other reason. Even if Qt
> upstream will now suddenly somehow become ultimately perfect, there
> still will be cases when we will need patches that will take time to
> find their way into Qt or where there won't be an agreement, yet we
> will need them, and I maintain that we need a place for those. That is
> even how qt-copy/patches started, for those that don't remember.

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. 

Whether distributors want to use that or something else, it's besides the 
point.

Qt SW's position = use qt.git
KDE's position = use kde-qt.git
Joe Developer's position = use joes-qt.git

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090527/803585ab/attachment.sig>