[Development] qtwebkit changes to qt/4.8

[Girish Ramakrishnan]

Hi QtWebKit team,
What's the best way to deal with patches to QtWebKit1/qt4 (for
example, http://codereview.qt-project.org/#change,21292) ?

Is the strategy still to get it all upstream? Since, I assume, there
is QtWebKit 2.3 planned how will this patch end up in Qt? (Is the
answer that it won't ever end up in Qt4?)

If the answer is to get it all upstream - would you agree that the
sanity bot should complain when anyone tries to commit to
src/3rdparty/webkit ?

Thanks,
Girish
_______________________________________________
Development mailing list
Devel...@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Girish Ramakrishnan]

Hi,

On Fri, Mar 30, 2012 at 4:57 PM, Girish Ramakrishnan
<gir...@forwardbias.in> wrote:
> Hi QtWebKit team,

> is QtWebKit 2.3 planned how will this patch end up in Qt? (Is the

Correction, I meant 'Since there is no QtWebKit 2.3 planned...'

[Simon Hausmann]

On Sunday, April 01, 2012 02:37:35 PM ext Kenneth Rohde Christiansen wrote:
> Hi there,
>
> We still are going to ship Qt WebKit1 API as part of the Qt5 module
> QtWebKitWidgets (I am not sure the name is final though) so it is a
> good idea to upstream I would say. Even things which are related to
> Qt4 only as the WebKit1 part should, to my knowledge, still work with
> Qt4, and who knows whether the community (or say Digia) wants to
> release a new version of QtWebKit for Qt4.
>
> Just my point of view

I agree with Kenneth. In general changes to Qt 4's WebKit should just
be backports from trunk. Ideally they're applied to the qtwebkit-2.2 branch
and then imported into src/3rdparty/webkit. The person approving the change
in Gerrit could forward-port the change to qtwebkit-2.2 on Gitorious and then
we fix the version and re-import into src/3rdparty/webkit shortly before the
next 4.8.x patch release. (This is more or less what I did for 4.8.2 now)

In this particular case the change hasn't happend upstream yet it seems, so
I agree with Girish's -1.

With regards to Qt 4 support in WebKit trunk, I think that unless somebody
steps up to care about and maintain the Qt 4 port, we should keep it around
around until Qt 5 is released and has become a viable alternative. Depending
on the quality and feedback that would ideally be Qt 5.0.0, but it could also
be a patch release or a minor release. After that point I think we should
remove Qt 4 support from trunk, unless a new maintainer is found.

Simon

> Kenneth
>
> On Sat, Mar 31, 2012 at 1:57 AM, Girish Ramakrishnan

>
> <gir...@forwardbias.in> wrote:
> > Hi QtWebKit team,
> > What's the best way to deal with patches to QtWebKit1/qt4 (for
> > example, http://codereview.qt-project.org/#change,21292) ?
> >
> > Is the strategy still to get it all upstream? Since, I assume, there
> > is QtWebKit 2.3 planned how will this patch end up in Qt? (Is the
> > answer that it won't ever end up in Qt4?)
> >
> > If the answer is to get it all upstream - would you agree that the
> > sanity bot should complain when anyone tries to commit to
> > src/3rdparty/webkit ?
> >
> > Thanks,
> > Girish
> > _______________________________________________

> > webkit-qt mailing list
> > webk...@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt