[Development] QtWebKit is coming back
Allan Sandfeld Jensen
kde at carewolf.com
Wed Jun 8 21:49:28 CEST 2016
I was asked how we used to structure and develop QtWebKit, and how it would
relate to the new project. So here some background and my thoughts:
The way QtWebKit used to be developed was upstream in WebKit, at some point a
release was branched and squashed into the qt respository in one big commit,
where we also removed all the layout tests which makes up the by far largest
part of the webkit repo.
The last branch of QtWebKit (originally branched for Qt 5.2) had three
different repos: WebKit upsteam, a fork of upstream living in gitorious where
our 5.2 git branch relative to upstream lived, and which was supposed to be
identical to the Qt-repo except supporting layout tests, and finally the
QtWebKit module in Qt repo. WebKit's build-system and CI ran on upstream
(equivalent to Qt dev), and on the the fork (equivalent to 5.2). Qt's build-
system and CI ran only on the Qt repo (basically only git tags).
Such a structure while workable is obviously not optimal, and even if we did
continue with such a 3 way model, it would be ideal if the upstream-fork could
be hosted together with the official qt version.
For an unofficial QtWebKit I would suggest just using an upstream fork on a
friendly git host. Being kicked out of upstream WebKit also means it would be
the only place of development. This is also how I maintained QtWebKit 2.3
which was a backport of modern QtWebKit to Qt4. Such as structure will however
become a problem if QtWebKit-NG needs to integrate with Qt build/CI system
again, since the repo would be a huge, unnecessary burden to check out, for
anyone who needs to just build or test it.
Note, it is not easy to split a WebKit repository and make the layout-tests a
submodule due to the sensible WebKit policy of always maintaining and adding
tests atomically with each commit that adds features that needs testing or
changes test output.
More information about the Development