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:
https://webkit.org/pending-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.
Benjamin
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?
Thanks,
_______________________________________________
webkit-dev mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-dev
