Bug 220690 – Haiku support upstreaming

• Status: RESOLVED
• Resolution: FIXED
• Component: Platform

[Alex]

Haiku has been re-basing patches for quite some time (since 2014) for our platform support.

After the recent git repo rewrite, I've done a major rework and cleanup of our historical patches and am maintaining them here:
  https://github.com/haiku/webkit-new/tree/haiku

I plan on re-basing and solving merge conflicts weekly until this code can be merged upstream.

Right now there are two "mega patches", one focusing on changes to shared code, one focusing on our platform code.


As of today based on feedback from the Webkit team, I have an approval from the Haiku, Inc. Board of Directors to pay for a
dedicated Haiku x86_64 CI builder for Webkit (likely hosted at Digital Ocean, we have full and stable virtio support)

The purpose of this bug is to track the overall status, and enable collaboration between Haiku and Webkit on which paths exist
to get our platform support upstream to enable our developers to focus on improving our platform support vs being consumed
with re-basing the large number of daily commits.

[Radar WebKit Bug Importer]

<rdar://problem/73551955>

[Fujii Hironori]

Does WebKit project approve this?
WebKit seems to have a rule of at least three full-time developers (Bug 214957 Comment 26).

[Pascal Abresch]

So far the (albeit minor) contributions I have submitted have been accepted. My understanding was that Webkit is generally receptive to patches and that a requirement for upstreaming is an ews builder (which we can do), and that we generally try to maintain the webkit port (we already do this, Adrien mostly rebases the port and madmad and me work more on improving it. )

Haiku currently only has one hired developer working mostly on Haiku itself, so we wouldn't match that atleast (if the understanding is correct that it need to be three developers employee for webkit alone?)

[Adrien Destugues]

Hello,

I am one active developer. I have been keeping the Haiku fork of webkit up to date with upstream since 2014. I am however not working full-time on WebKit at the moment (Haiku is not my current paid job, and I have many other things I work on in Haiku).

Recently Pascal Abresch has started submitting some patches from our fork to WebKit upstream. He started with bug fixes in shared code that also helps other platforms. He is also not working full-time on this for similar reasons.

I don't know what the best balance is here. Currently most of my time on WebKit is spent just merging changes from upstream and fixing trivial merge conflicts and build problems. As a result I try to write the Haiku port code while touching as few of WebKit common files as possible to avoid merge conflicts. I think this is not ideal, and it would be better if these changes could be handled by WebKit developers for the simplest cases.

Every part that can be upstreamed results in less work for me in just keeping things up to date. Hopefully I can then use my time for more interesting things. I don't know if upstreaming everything is the right approach, but how could we split this otherwise?

One thing to know is we are still using WebKitLegacy. As a result, our changes are in WebCore (largely in platform-specific files) and WebKitLegacy (completely separate from the other ports there, there is no common code between platforms in WebKitLegacy). We will eventually migrate to WebKit2, but that part isn't working yet. From my experience, the WebKit2 part would be where there is more changes to shared files and more conflicts.

[Don Olmstead]

Pascal asked about this over in Slack so I'm just going to chime in with some of those thoughts over here too.

One thing you all might be able to do is do a JSCOnly port that works on Haiku. We have code for OS(FUSCHIA) in there already and I don't know that anyone in the community at large is building that target so it seems reasonable for Haiku.

Another thing for you in general is if you can share code with other platforms thats a win for your port. The PlayStation and WinCairo ports share curl as a networking backend and working on curl was a great way to get involved in the community.

As a team that has gone from a similar situation as Haiku, a completely downstream port with all the headaches involved with that, to living largely upstream I definitely feel for you folks. The developer requirement is more about trust than anything. When someone modifies code that has effects on other ports having someone available to help is key otherwise the port eventually stops working and then the port gets removed.

Maybe a JSCOnly port is a good starting point for you all?

[Adrien Destugues]

> The developer requirement is more about trust than anything. When someone modifies code that has effects on other ports having someone available to help is key otherwise the port eventually stops working and then the port gets removed.

I know, in fact the Haiku port was already upsreamed once in 2010 and removed again 2 years later for lack of maintenance.

All I have to offer is 7 past years of work rebasing and keeping our port up to date. I did not attempt any upstreaming efforts on my own because I knew I wouldn't have time for it. Now that Pascal is helping, it seems more reasonable.

Being mainly a volunteer driven project, it's unlikely that we will have 3 full time developers for webkit anytime soon. That doesn't mean we aren't committed to keeping this port alive and up to date.

I think it makes sense to start with a jsc-only port in any case. So let's do that (if it's ok on webkit side) and we can discuss the next steps later?

[Pascal Abresch]

I would be okay with upstreaming and maintaining (that is, to be the person to be cced to haiku tickets and try to solve them) a JSConly port for now.

Assuiming Haiku Inc provides an ews builder to build the JSCOnly port for Haiku would that be acceptable to the webkit project?

[Brent Fulgham]

I don't think we would want to bring on another port that is based on WebKitLegacy. We are working hard to remove WKL from the tree, and any new dependencies on the deprecated stuff would be bad.

[Alex]

> I don't think we would want to bring on another port that is based on WebKitLegacy. We are working hard to remove WKL from the tree, and any new dependencies on the deprecated stuff would be bad.

Haiku is hard at work trying to move away from WebKit Legacy and has a some early code using the more modern components.

The difficulty we run into is maintaining the new code in a fork of the *rapidly* moving webkit code base.

As a bare minimum entry point, getting the shared code merged would be extremely helpful in empowering our current developer base to keep up.

For example, anything Haiku platform build related (not WebKitLegacy related) in common code locations.   This would prevent the need for our limited subset of developers working on webkit to be continuously rebasing our changes over the latest rapidly moving Linux/Mac/Windows master code, and let them focus on getting the webkit code refined.

The above is why we have had problems even moving away from WebKitLegacy.  We have developers with the skillsets needed... we just don't have the (wo)man power to keep up with the army of Linux/Windows developers changing common code.

[Adrien Destugues]

I don't think he would upstream the WebKitLegacy parts indeed. Let's start with the jsconly port (which will not be a lot of code) while I keep working on getting WebKit2 running on Haiku?

[Pascal Abresch]

Indeed, For now a JSCOnly port would be a good step in the direction of better cooperation with webkit upstream, I don't care to upstream webkitlegacy code for Haiku in any case, so if anything this would be webkit2 code later down the line once haikuwebkit has switched to it and it works reliably.

Regardless of whether a JSCOnly port is accepted at this time I will work to try and upstream any fixes haikuwebkit has to shared code.

[Adrien Destugues]

Pull request: https://github.com/WebKit/WebKit/pull/33893

[EWS]

Committed 283988@main (a01808f893e2): <https://commits.webkit.org/283988@main>

Reviewed commits have been landed. Closing PR #33893 and removing active labels.

[Pascal Abresch]

This should not be marked fixed, the port is not upstreamed. Only basic OS detection. It seems to me that the closure was automated by the que?