Wed Aug 1 07:28:53 PDT 2012
cp -r Source/WebKit2 Source/WebKit2NonApple/
(git revert the mess that with the frameloader?)
git add Source/WebKit2NonApple/
> Major changed might just cause more harm, minor incremental ones are
> less disruptive and hopefully when well considered, will bring us
Sure, but that is us playing the game, where Apple clearly does not.
> I still support this move
I still support *a* move.
> On Tue, Jan 22, 2013 at 9:33 AM, Pozdnyakov, Mikhail
> <mikhail.pozdnyakov at intel.com> wrote:
>> Right, API part is not that big part and moving it out alone would not g=
ive much benefits.
>> Is our main problem in upstreaming patches within this particular area?
>> I think the real problems that we have (for instance if some APIs are st=
opped being supported on generic WK2 level) are not gonna be solved
>> with this minor movement.
>> Furthermore reviewing our patches by Apple guys has advantages as they h=
ave better understanding of WK2 architecture and plans
>> for its modification (which we are not aware).
>> From: webkit-efl-bounces at lists.webkit.org [webkit-efl-bounces at lists.webk=
it.org] on behalf of Vyacheslav Ostapenko [ostap73 at gmail.com]
>> Sent: Monday, January 21, 2013 7:52 PM
>> To: webkit-efl at lists.webkit.org
>> Subject: Re: [webkit-efl] Moving the EFL WebKit2 public APIs to outside =
>> Hi All,
>> 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 struct=
ure of WebKit2 there and move all the code that is not compiled by Apple, l=
ike 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 gma=
il.com<mailto: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 mo=
>> Source/WebKit2/UIProcess/API/efl/ (public headers) -> Source/Platform/ef=
>> 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<mailto:webkit-efl at lists.webkit.org>
>> Intel Finland Oy
>> Registered Address: PL 281, 00181 Helsinki
>> Business Identity Code: 0357606 - 4
>> Domiciled in Helsinki
>> This e-mail and any attachments may contain confidential material for
>> the sole use of the intended recipient(s). Any review or distribution
>> by others is strictly prohibited. If you are not the intended
>> recipient, please contact the sender and delete all copies.
>> webkit-efl mailing list
>> webkit-efl at lists.webkit.org
> Kenneth Rohde Christiansen
> Senior Engineer, WebKit, Qt, EFL
> Phone +45 4294 9458 / E-mail kenneth at webkit.org
> webkit-efl mailing list
> webkit-efl at lists.webkit.org
Software Engineer @
Intel Open Source Technology Center
More information about the webkit-efl