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

Simon Hausmann simon.hausmann at nokia.com
Mon May 14 01:16:00 PDT 2012

On Friday, May 11, 2012 07:36:09 PM ext Allan Sandfeld Jensen wrote:
> 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.

Yes, excellent point.
> I do not think cherry-picking from trunk is viable option in the long run.

I agree.

> 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.

Right, if there are things we can do in trunk to make it easier, then we 
should do them.
> 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.

What do you mean with keeping? Just keeping the sources around? Or keeping the 
bot up as well and trying to keep it green?


More information about the webkit-qt mailing list