[webkit-dev] Upstreaming the Haiku port again
benjamin at webkit.org
Tue Oct 7 12:47:18 PDT 2014
I believe it is better for Haiku to remain out of the main tree until
the project gains at least 2 reviewers.
Without dedicated reviewers, you will struggle to integrate any patch
because nobody in the WebKit project is familiar with the Haiku
platform. To give you an idea of how huge the backlog is, look at the
list of patches currently waiting for review:
The best way forward is to start making patches for the fixes you have
made that are independent of any platform. An other kind of patches is
any refactoring that improve platform abstractions. Cleaning up the code
this way should make it easier for you to work on a branch.
Those fixes would go toward a nommation as committer, then reviewer.
Without multiple reviewers, it is just impossible for a port to thrive
on the main branch.
Note that having reviewers is not a enough to upstream a port, you would
be expected to contribute to the core. But I believe it is a necessary
condition for success.
What are the major pain points today of developing Haiku WebKit in a
branch? The first step is addressing those in the main branch.
On 10/7/14, 6:22 AM, pulkomandy wrote:
> Hello WebKit,
> For about one year now I've been working on updating and improving the
> Haiku port of WebKit. This was upstreamed once in 2010, but then went
> unmaintained for a long time and was dropped from WebKit SVN.
> We have learnt from this failure (I hope) and we are ready to do another
> upstreaming attempt:
> * We are now using git instead of SVN, making it much easier to track
> changes in WebKit and keep our port up to date (I'm merging changes
> more or less every week)
> * I'm working full-time on this, as long as our users continue donating
> enough money to the Haiku project to fund my work. So I can spend the
> needed time keeping things working
> * We have switched from Jam to CMake, and we share most of the build
> files with the other ports using CMake
> * We have allocated a machine to run a buildbot slave for WebKit
> The current sources can be viewed at https://github.com/haiku/webkit (in
> branch "rebased").
> I would like to use the upstreaming as an opportunity to get the code
> reviewed by other WebKit developers, and for this I plan to extract
> patches from this source tree, and cut them in chunks of reasonable size
> for review.
> Do you see any problem with this? Should I start with setting up the
> buildbot, or should I first start submitting patches? In the latter
> case, is starting with Tools/Scripts the right thing to do?
> https://trac.webkit.org/wiki/SuccessfulPortHowTo suggests patches should
> be smaller than "20k". Is that bytes, lines of code, or some other unit?
More information about the webkit-dev