WebKit upstreaming plans and coordination

[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).

[nephele]

One tinier patch to be upstreamed ​https://bugs.webkit.org/show_bug.cgi?id=232165

so far no response from webkit though :/

[pulkomandy]

Lack of response is probably due to not following the needed process for patch submission.

It is documnented here:

​https://webkit.org/contributing-code/

The main parts are:

• Use the webkit-patch script to generate your patch and upload it to the bugtracker. It will make sure you have a good commit message, an entry in the changelog, etc. Patches submitted this way will automatically run through the "ews" which will check it does not break the build or tests for other platforms (and, unfortunately, not yet for Haiku, we should set up an EWS builder someday...)
• You need to mark the patch for review using the "r?" tag, otherwise no one will look. Or you can assign a reviewer directly if you already know someone who is familiar with this particular area of the code, or has said they are interested in helping with Haiku upstreaming.
• After review, the reviewer will set the "r+" flag and maybe the "commit-queue:+" flag to merge the thing.

[nephele]

Next patch: ​https://bugs.webkit.org/show_bug.cgi?id=45113