WebKit upstreaming plans and coordination
|Reported by:||pulkomandy||Owned by:||pulkomandy|
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).