Review Request 109503: Compile with current qt dev branch

David Faure faure+bluesystems at kde.org
Sun Mar 17 15:12:33 UTC 2013


On Sunday 17 March 2013 13:51:39 Stephen Kelly wrote:
> Ben Cooksley wrote:
> > Long term we either need:
> > 1) A commitment from the Qt project to make keeping qt5.git updated a
> > high priority (block all new commits from entering any submodule until
> > the issues in question are fixed for instance) or
> > 2) We need to decide to adopt either qt5.git or individual submodules
> > as our only supported build option.
> 
> Ok, if you want to revert the change and use pristine qt5.git I'm fine with
> that too.

Yes, I'd rather that we go back to qt5.git.
It represents a stable base for everyone, so we all use the same version of 
Qt5.

Otherwise we'll have all the temporary breakages from qtbase dev creating 
trouble (e.g. someone commits a SIC, we realize the next day, it's fixed the 
day after, meanwhile KF5 contributors who updated Qt5 fix compilation to the 
new API, breaking things for KF5 contributors with an older qt5, and then when 
the revert comes in, we get to undo our changes, breaking compilation yet 
another time for people who didn't update yet...).
And meanwhile we lost a large number of developer hours, because people were 
watching qt5 recompiling instead of working on KF5 itself.

Using qt5.git simply requires being patient after we get something into Qt, 
since it takes time to propagate up to qt5.git. But there's enough to do 
meanwhile...

And we can always help the Qt devs updating qt5 faster. Right now it seems to 
require a stable->dev merge for qt5.git, which failed in one unittest, I'm 
actually setting up for testing if I can reproduce that.
https://codereview.qt-project.org/#change,49698

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by BlueSystems and KDAB to work on KDE Frameworks



More information about the Kde-frameworks-devel mailing list