[webkit-dev] Archiving the Haiku port? (was WebKit2 and all that jazz)

Gustavo Sverzut Barbieri barbieri at profusion.mobi
Tue Apr 13 12:20:56 PDT 2010

On Fri, Apr 9, 2010 at 2:09 PM, Stephan Assmus <superstippi at gmx.de> wrote:
>> ----- Ursprüngliche Nachricht -----
>> Von: Adam Barth
>> Gesendet: 09.04.10 23:26 Uhr
>> An: webkit-dev at lists.webkit.org
>> Betreff: [webkit-dev] Archiving the Haiku port? (was WebKit2 and all that jazz)
>> Is the Haiku port actively maintained?
>> http://trac.webkit.org/browser/trunk/WebKit/haiku/
>> Looking at the ChangeLog, I don't see any real activity:
>> http://trac.webkit.org/browser/trunk/WebKit/haiku/ChangeLog
>> Maybe we should archive it? I certainly don't want to exclude Haiku
>> from the community. Ideally, we'd make it easy to unarchive it if
>> folks appear who want to work on it again.
> I am actively working on the Haiku port. I have submitted a number of patches, but since the review process takes _very_ long (no offense intended) I am careful to only submit patches when I don't anticipate changes to the files in the near future. A few of my patches still just sit there in bugzilla. Some got reviewed, the last activity was on a patch to ImageBufferHaiku.cpp, where the reviewer gave an r- because I removed the original copyright. Myself and Maxime Simone (original copyright holder) explained the issue and why it was correct to remove it. However, no response from the reviewer since then.
> I have a *huge* number of additional patches, since I am writing a WebKit browser for Haiku, completing the port, the Haiku WebKit API and the browser. Many of the patches would simply not be small, and to be frank, the review process has so far discouraged me from even trying to submit any of the bigger stuff. Especially the stuff I am working on all the time.
> I can certainly prepare updated patches and new patches in the next days, but it takes careful preparation and if those patches just sit there in bugzilla and receive no further feedback after initial review... it is just not motivating if the initial review came after about 10 days in the first place.
> The problem is of course that there are no dedicated Haiku reviewers. Other ports have their own number of reviewers and people interested in getting patches for their ports landed. With Haiku it's a chicken and egg problem. As long as I don't get a significant amount of patches landed, I won't even become committer.
> I don't really know what a solution could be. The Haiku port touches no other code, it's pretty self-contained. In that respect the chances are very low to affect other ports/people. I don't know if that could be an argument for just rubber stamping a lot of patches until the Haiku code in the official repo includes most of my stuff. What do you guys think? IMHO, the problem with the Haiku port is certainly not that it is not actively maintained, I work many hours on it each day, the problem is how to get the patches into SVN smoothly.

Unfortunately this review issue is also adding huge latency to
WebKit-EFL, that we're trying to introduce. Some patches are quickly
reviewed with r-, then we try to fix the issue by providing more
patches but they lag behind.

We all know that reviewing other port is not the most interesting
stuff in the world, particularly those that you cannot or do not have
interest in testing, but it would be good if at least the initial
landing was bit faster so we can have buildable systems :-)


Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
MSN: barbieri at gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

More information about the webkit-dev mailing list