[webkit-dev] It's time to remove the Haiku port

[Ryan Leavengood]

On Fri, Nov 4, 2011 at 12:33 PM, Peter Kasting <pkasting at google.com> wrote:
>
> It seems like either you should be a private fork/port, or a public
> upstreamed one, but not both.  If you want to live in the upstream tree, I
> think most of your development work should land quickly in public.  If you
> want to work in a separate repository without landing changes back upstream
> quickly*, I think it's better to stay private until the point at which that
> changes.

Yes, this was definitely the hard lesson we learned, and as I'll
describe below we are going to move to the latter set up for now.

> *At most I don't think your private repo should be more than a couple weeks
> off the public repo.

Most definitely, I will strive to do that from now on :)

> Based on our experience with the Chromium port I think it would be far
> easier on your group to be public and do development directly in the public
> tree.

That is definitely our end goal. But it seems at this point the Haiku
port is too much of a burden to the WebKit community. I talked to Adam
Barth in IRC last night and we came to an agreement that it is best
*for now* if Haiku maintains a Git repo cloned off the WebKit repo
with a branch containing our port. When our port is further along with
layout tests working, most of the platform files implemented, a
Buildbot, and maintainers with the time and skill to keep our port
up-to-date, we can explore putting our code back in the public WebKit
repo.

This puts the burden on maintaining our port where it belongs: with
our developers. It won't always be fun doing it this way, but I think
using Git will help (as compared to Subversion which is where our
current copy of WebKit is, and now almost 42,000 changesets behind.)

Actually regarding the 42,000 changesets: these have all come in the
last year and a half (!!!!), and are almost as many changesets as ever
came before in the current WebKit repo. This is exponential growth!
How is a small port possibly suppose to stay up-to-date under those
conditions? Of course this just means that WebKit is a vibrant project
and you cannot be faulted for that, but I think with this onslaught of
changes it may be time to reconsider past methods of keeping ports
up-to-date. Adam tells me Google has two full-time engineers keeping
the Chromium port up-to-date. I think there is room for improvement in
this area.

Actually I have various thoughts about WebKit platform code which I'm
sure many of you would agree with, but I can express those in another
email. The short version is WebCore should have no platform code or
PLATFORM macros and all platform code should plug in using clean
abstract classes and delegates. Maybe this is an area where I or other
Haiku developers can give back to the WebKit community.

I just hope that when that time comes (and maybe sooner rather than
later) the WebKit community will let us back in and quickly apply our
patches.

-- 
Regards,
Ryan