Am Sunday 30 August 2009 15:15:33 schrieb Alexis Ménard:
> Qt 4.6 will be released end of this year which means that distribution will
> probably do the same story that they did with 4.2 and Qt 4.5 (i.e ship 4.5
> regardless of the non-testing aspect). So should we based the trunk on top
> of 4.6 for KDE 4.4?

If the bugs/regressions in Qt 4.6 are fixed long enough before the KDE 4.4 
feature freeze, this discussion might eventually make sense again. IMO KDE 
trunk can not require Qt 4.6 at this point in time (yes, I try origin/4.6 
from git daily).

Regarding bug reporting, there is no "Qt 4.6 snapshot" or similar entry on the 
web bug report form. How should regressions be reported? Reporting bugs via 
IRC only works for "thiago business hours" (that is 24/7), but unfortunately 
he can only help with "core" stuff. The regressions are in GUI stuff mostly.

<ignorethis>
I would love to help triaging/fixing bugs, but the current Qt infrastructure 
sucks. It may be my personal defiency to get used to git, but I am much more 
productive with the current svn/bugs/reviewboard KDE combo. Those merge 
requests just limit my productivity. The "we cannot care about bugs reported 
to kdelibs/qt and patches applied to qt-copy" just adds to this.

Ideally, I would just svn commit to qt-copy with a fix, add a BUG: or a 
QTISSUE: number, and request merging with upstream Qt using a QTMERGE tag. 
Done. It cannot get simpler. Post-commit review works.
</ignorethis>

Christoph Feck (kdepepo)