RFC: remove qt-copy

[Thiago Macieira]

Em Terça-feira 26 Maio 2009, às 10:15:22, Sune Vuorela escreveu:
> The software we are packaging is Qt as released by Trolltech/QtSoftware
> with a set of patches on top, not anything else.
> The origin of the patches is in my eyes not that relevant, but the
> patches themselves are relevant, and the possibility to assess the
> possible side effects and the revertability of the patches.
>
> It is also a matter of "is this bug important enough to warrant another
> divergence from Qt as released by Trolltech/QtSw". Just as stable
> release policies and other such things, this differ between
> distributions, between distributions and KDE, between distributions and
> Trolltech/QtSw
>
> oh. and btw, I have at several times discussed Qt-copy patches with
> people from Trolltech/QtSw, and they often wasn't very impressed by
> some of the patches and urged me to not ship them.

I'm with Sune here.

First of all, Qt Software's position is that you shouldn't patch Qt at all. 
We'd prefer that qt-copy existed only as a *copy*. And with the switch to Git, 
we'd prefer it be completely dropped -- no kde-qt.git.

But if I now put my KDE hat on, there's the need for a staging are for patches 
that Qt Software has not accepted or has rejected, but are still needed. For 
example, Luboš's checkWindowRole patch (0180). Those are patches to Qt that 
KDE strongly suggests distributors to ship.

As for distributors, I'd say they should really know what they ship. Blindly 
trusting any source isn't a good idea. Ideally, they'd run tests to make sure 
that the updates don't break anything. But on practical terms, I think the 
best we can hope for is that the packager analyse the patches and decide what 
to ship.

This has been like that for a while: ever since Qt 3, distributions have 
distributed Qt with a set of patches that is not equal to qt-copy patches. 
They have chosen not to ship some that are there and they have added some 
patches of their own too.

(BTW, one of the Qt3 patches was binary-incompatible and was shipped by all 
distros -- probably still is)

Another use-case for kde-qt is the developer environment for KDE developers. 
This will include not only KDE-created patches, but also fixes cherry-picked 
from Qt's own tree. That's exactly what the "4.5.1-patched" branch is right 
now.

Developers who may want to follow Qt development *and* apply the KDE-created 
patches will have to do that on their own. It's actually easy with Git.

> No. How do packagers and others know when there is something updated?

How did you do it before?

> >> What happens the day someone
> >> accidentally pushes some BIC change to kde-qt at the time the
> >> distributions choose to snapshot it?
> >
> > we don't do BIC changes
>
> Who watches over it ?

"Given enough eyeballs, all bugs are shallow" - Linus Torvalds

> And once again. How do I easily extract the seperate patches from the
> git repository ?

http://qt.gitorious.org/qt/kde-qt

There's a list of branches there. If you click on any branch, the patch is the 
topmost commit. If you click on it, you can get the raw patch, including 
author name, timestamp and commit message.

Or, with the tool itself:
	git format-patch v4.5.1..4.5.1-patched

That creates one file for each patch.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Software
      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/20090526/f755f335/attachment.sig>