[webkit-qt] Proposal: Qt 4 removal from trunk, Qt 5 changes

Allan Sandfeld Jensen kde at carewolf.com
Fri May 11 10:36:09 PDT 2012

On Friday 11 May 2012, Jocelyn Turcotte wrote:
> On Fri, 11 May 2012 16:47:02 +0200
> ext Andrea Diamantini <adjam7 at gmail.com> wrote:
> > Ok,
> > let's say it will be easier for you to remove Qt4 bits. I can live with
> > that. I will just stop merging back from master one commit before and
> > then try to cherry-pick webcore fixes.
> > Do you have an hypothetical data for this?
> I think it would be nice to keep the possibility of rebasing/merging the
> branch on top of the state of trunk. But I'm not sure if keeping the
> Qt4-specific code in trunk would help this anyway.
> The only real benefit I see of keeping the Qt4 code in trunk is if somebody
> would prefer to contribute/testing something there instead of on a
> possibly out-dated branch. But if nobody regularly compiles this
> configuration on trunk, it will soon become broken enough to make it more
> comfortable on the branch anyway.
Hopefully one of the things that will come out of Andrea's branch is 
upstreaming improvements from KDE contributors. Right now that is not 
happening, but the idea is to move in that direction.

I do not think cherry-picking from trunk is viable option in the long run. I 
see two options if we remove Qt4 support in trunk, either try to skip that 
commit in the branch, and carefully merge or skip later commits that touches 
the code (hopefully not much), or rename the Qt ports so that changes in qt4 
and qt5 ports doesn't cause conflicts.

Still in both cases we would need to keep Qt4 support in WebCore to not make 
things completely impossible, or alternatively split qt4 and qt5 here as well.

I still see keeping qt4 for the time being as the most optimal solution. 
Anything else is likely to kill the qt4 port before it has even started.


More information about the webkit-qt mailing list