[webkit-efl] Moving the EFL WebKit2 public APIs to outside WebKit2 directory
ostap73 at gmail.com
Mon Jan 21 09:52:04 PST 2013
Why only API part? I think everything that is not used by apple should go
outside of Source/WebKit2.
We should create something like Source/WebKit2Ports, shadow the structure
of WebKit2 there and move all the code that is not compiled by Apple, like
APIs, CoordinatedGraphics, shared memory and process mangement and etc.
Of course it will not solve the problem of Apple breaking Qt, EFL and GTK
ports, but at least it will allow easier fixes of port specific issues.
On Mon, Jan 21, 2013 at 11:48 AM, Thiago Marcos P. Santos <
tmpsantos at gmail.com> wrote:
> Hi Ewkitters,
> The recent changes on the reviewing policy for the code located inside
> Source/WebKit2 directory has been affecting the speed of how the EFL
> port moves forward. The additional burden for the WebKit2 Owners to
> review code from all the the ports has obviously its implications. We
> have red bots for days because of pending patches.
> We can minimize this overhead and let the WebKit2 Owners focus on
> reviewing the core components by moving the EFL WK2 public API and
> unit tests to outside the Source/WebKit2 directory. The best place I
> see would be Source/Platform/efl, which will be consistent with how
> the Chromium API files are placed inside the WebKit tree.
> This is the directory structure I'm proposing (using Chromium as role
> Source/WebKit2/UIProcess/API/efl/ (public headers) ->
> Source/WebKit2/UIProcess/API/efl/ (the rest) -> Source/Platform/efl/src
> Note that we are initially moving _only_ the API and utests. Other
> things, which are probably 5% of what is left of EFL code, can be
> moved later if needed.
> Comments anyone? I'm volunteering myself for the task.
> webkit-efl mailing list
> webkit-efl at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-efl