#15252: WebKit upstreaming plans and coordination
--------------------------------------+------------------------------
Reporter: pulkomandy | Owner: pulkomandy
Type: task | Status: new
Priority: normal | Milestone: Unscheduled
Component: Applications/WebPositive | Version: R1/Development
Keywords: | Blocked By:
Blocking: | Has a Patch: 0
Platform: All |
--------------------------------------+------------------------------
As I overheard some discussions on IRC, we may as well have this clearly
written down somewhere.
Currently our WebKit lives as a fork of the upstream repo. It used to be
upstream, but then we didn't push any updates for two years or so and
eventually they dropped the upstream support. Since then, I have been
largely (but not completely) alone maintaining the Haiku WebKit port, and
I could not work on all things: keeping up to date with upstream, fixing
bugs, and getting our changes back into upstream again. I focused on the
first and some of the second, as time allows.
It may be time to reconsider this. However we have to be sure we can keep
up with keeping our upstream port up to date, this probably means more
frequent changes to it, in order to not be annoying other WebKit devs who
would be struggling to keep things working for us.
Given that our current port is a bit of a mess in terms of git history
(lots of merging, parts of the commits originally based on an early git-
svn checkout rather than the official github mirror of webkit, etc), and
given WebKit review process, there is not much point in trying to keep our
git history. Rather we should review the changes and split them again into
commits that make sense for upstream.
This work will probably start with the support scripts (webkitpy,
webkitperl, etc) and then with WTF then WebCore. WebKitLegacy is probably
not worth upstreaming. It is likely that WebKit team will require us to
provide buildbots for their EWS system, which builds patches sublitted to
review on their bugzilla and checks they are not breaking any platform. We
need buildbots fast enough that they can keep up with the submitted
patches for WebKit.
Sending patches upstream is done with a script that helps following the
process: updating the Changelog file, preparing the patch with the commit
message, and sending it to bugzilla for review. Then one needs to fold in
the review comments (there is going to be a lot, on code formatting we
didn't really follow webkit rules...). Also, any change to the core will
require providing matching tests to show what is being fixed.
We still need to keep our own fork somewhere so we can tag releases on it,
and also because we will probably need some time before everything is
reviewed and upstreamed. At first it will be by merging the upstream
changes (as it was done until now), and hopefully someday we will have
upstreamed enough that we can archive this very old branch and start fresh
(that could save quite some size for the git repo, I think).
--
Ticket URL: <https://dev.haiku-os.org/ticket/15252>
Haiku <https://dev.haiku-os.org>
The Haiku operating system.
