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

Turunen Tuukka Tuukka.Turunen at digia.com
Tue May 15 23:45:01 PDT 2012


Hi Simon et al,

We would like to:

* Have an updated webkit for Qt 4.8

        * Not make Qt 4.9, but keep Qt 4.8 viable and in long run get everyone on board to Qt 5

        * Keep the webkit work inside Qt Project, if at all possible

Reason for having the webkit of 4.8 updated with new(er) version from the trunk is the expected long lifetime of 4.8. We do not want to change the API or bring new major features, just to keep the things we have in Webkit 2.2 up to the challenges in the years ahead for Qt 4.8 based solutions.

It is great that Andrea (and others) is willing to maintain. But why does it mandate removal things from where they now are? I think it would be easier for everyone if we can keep working with the current approach.

Timewise the new webkit version, say 2.3.0, could then be included to 4.8.3 or 4.8.4 release provided that compatibility is maintained.

We are ready to help with this item. Not to be the maintainer, but have some engineering time allocated to help in creating this, and integrating it to 4.8 patch releases. At the very moment we are quite busy with the things ongoing to get Qt 5 out in time, but after summer we should be able to allocate some time for the new webkit for 4.8. And if it happens before, we are anyway very much willing to get it in to the 4.8.x patch releases when possible.

Yours,
--
Tuukka Turunen
Director, Qt Commercial R&D
Digia Plc
Piippukatu 11, 40100 Jyväskylä, Finland

Visit us at: www.digia.com<applewebdata://7FB7E1CD-55A7-4FAD-B1A5-7721230C2E29/www.digia.com> or qt.digia.com<http://qt.digia.com/>

On Monday, May 14, 2012 04:31:12 AM ext Dawit A wrote:

> On Fri, May 11, 2012 at 10:10 AM, Simon Hausmann
>
> <simon.hausmann at nokia.com<http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt>>wrote:
> > On Thursday, May 10, 2012 09:55:47 AM ext Allan Sandfeld Jensen wrote:
> > > On Wednesday 09 May 2012, Simon Hausmann wrote:
> > > > Hi,
> > > >
> > > > After a few emails, let me formulate a concrete proposal:
> > > >     (1) Andrea Diamantini maintains an up-to-date port of WebKit that
> >
> > runs
> >
> > > > with Qt 4, on gitorious.org.
> > > >
> > > >     (2) End of May we remove Qt 4 code paths from WebKit trunk.
> > > >
> > > >     (3) We replace the Qt 4 based bot on build.webkit.org with the Qt
> >
> > 5
> >
> > > >     one
> > > >
> > > > (hosted on Amazon, right?)
> > >
> > > After some thought, I think we should maintain atleast one stable
> > > desktop
> > > version of QtWebKit in trunk, and I believe Lars already officially
> >
> > stated
> >
> > > that Qt 5.0 will not be fully ready for the desktop, so I suggest we
> > > maintain QtWebkit for Qt 4.8 until Qt 5.x is deemed ready for the
> >
> > desktop.
> >
> > > Since we only support Qt 4.8 for WebKit1 where not that much development
> >
> > is
> >
> > > happening, how much would we gain in dropping that support anyway?
> >
> > It's a fair question, and I admit I didn't outline that in the proposal.
> > The
> > maintenance of the Qt 4 port currently costs us
> >
> >     (1) Separate *Qt4.cpp files in a few places (including the much loved
> >
> > JSC<>QT bindings ;)
> >
> >    (2) A fair chunk of #ifdefs
> >
> >    (3) A bot to maintain (This is a very high cost, especially for Ossy).
> >
> > I'm proposing the remove the Qt 4 port from trunk because nobody appears
> > to be
> > interested in taking over that maintenance in trunk. Andrea on the other
> > hand
> > volunteered to do an out-of-trunk maintenance, which is a great
> > opportunity I
> > thought.
>
> What exactly is involved in maintaining it in the trunk itself ? Would such
> maintenance require more than one person ?  I just do not see how the
> out-of-trunk maintenance is supposed to work.

In-trunk maintenance requires keeping a bot green and regularly catching up
with changes that happen in WebKit. If we just keep the Qt 4 code in trunk and
let it "rot" then for a while people will continue to blindly change the Qt 4
files if they do internal API changes, but that'll stop sooner than later. Then
the code becomes bitrot and it looks bad.

An out-of-trunk maintenance requires probably more effort in merging itself,
but it's completely up to the people maintaining it _when_ they choose to do
it and how long it'll take them.

> For example, if a 2.3 version
> of QtWebKit was supposed to be released from such branch, how would that be
> treated ? Would it be considered an official update of QtWebKit for Qt4 ?

I doubt that Digia or anyone else is going to roll a new Qt 4.9, so in the light of that it would be a standalone release. Available to interested
parties who would like a newer version of WebKit with Qt 4.x.

It's in our hands :)


Simon



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-qt/attachments/20120516/35176155/attachment-0001.html>


More information about the webkit-qt mailing list