l.lunak at suse.cz
Mon Jun 30 18:12:34 BST 2003
in case you haven't noticed yet, I've added a new directory patches/ to
qt-copy. Even though it at first my look only as if I'm upset by the fact
that most of these patches hang in qt-bugs@ for months, I actually see good
reasons for having patches in qt-copy (also, this is not only my idea - when
I mentioned creating patches dir for qt-copy, several people seemed quite
happy with the idea, and I'm quite sure there won't be only my patches):
- First of all, those 'patch applied and sent to TT' commits get lost with
next qt-copy update, if the patch didn't make it yet into official Qt.
Keeping changes in qt-copy also as patches will make reapplying them easier.
- Keeping changes in qt-copy as patches should also make it easier to see how
it differs from official Qt, and since some packagers use qt-copy for
building their Qt packages, they can see what the differences are, and can
pick ones they like.
- There is usually a bunch of patches handing in qt-bugs@ queue that improve
some part of Qt noticeable, yet it can be months before somebody else then
the patch author will be using the patch. To mention some of my patches,
there are e.g. QPixmap<->QImage optimizations that make noticeably faster
large images handling, there's a DND optimization that makes DND feel much
faster, or there's a patch that makes the menubar applet obey Fitts' Law.
- Even though the patches should be very well tested, one can never test
something too much. If TT hesitate to apply a patch, let's test it for them.
- blah blah blah
- oh, and yes, I'm upset by the fact that some of my patches hang in qt-bugs@
for months. While I can understand that TT can't fullfil my every wish even
if it includes a patch, just like the same happens with bugs.kde.org etc.
(hate mails requesting KHotKeys2 finally being finished are welcome), that
doesn't change anything on the fact that I don't like it, and having the
patches in qt-copy will also have the additional benefit of making me less
Now, the intention is not to fork Qt or anything like that. I've still kept
my sanity ... hopefully ;). The patches in qt-copy/patches/ shouldn't make
qt-copy incompatible with official Qt. There should be fixes, optimizations,
and similar stuff.
However, I've also created directory qt-copy/patches/notsafe, which should be
for patches for which the above doesn't apply, for various reasons, the most
common one being TT's extreme resistance to adding even the simplest new API
to a stable release. Such patches should never be applied to qt-copy, and no
code in CVS should rely on it. The patch of mine that's currently there quite
likely won't make it in time for Qt-3.2, and if it will be so, KWin in KDE3.2
will have a configure check and one of its best new features will be enabled
only with patched Qt :(.
If you add new patches, please:
- include the qt-bugs@ issue number
- explain what it does (pasting the qt-bugs@ mail will do ;) )
- keep the numbering, so that people know in which order to apply the patches,
in case they depend on each other
- don't add crap
Comments, flames, suggestions, requests demanding my head?
SuSE CR, s.r.o. e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27 tel: +420 2 9654 2373
190 00 Praha 9 fax: +420 2 9654 2374
Czech Republic http://www.suse.cz/
More information about the kde-core-devel