On Mon, Jan 21, 2013 at 4:32 PM, Claudio Saavedra <[email protected]> wrote: > On Mon, 2013-01-21 at 15:27 +0100, Xan Lopez wrote: >> On Mon, Jan 21, 2013 at 2:53 PM, Mario Sanchez Prada >> <[email protected]> wrote: >> > Hi, >> > >> >> (...) >> >> > >> > If anyone could drop some light on this issue or provide some pointers to >> > better understand the motivation of this change, I’d really appreciate >> > that. >> > I understand rolling r140285 might be not the best option at this point, >> > yet >> > I’d personally rather not keep the WebKit2GTK+ broken for too long. >> >> As has been discussed in the list (see >> http://lists.webkit.org/pipermail/webkit-dev/2013-January/023255.html) >> the new development model for WebKit2 basically means this can happen >> at any time, and the broken pieces are for each port to keep and put >> back together. So I doubt reverting the patch is an option (in fact >> this is essentially the intended result of the new policy), we just >> need to figure out how to deal with this as fast as we can (which I >> think will be "too long" by any reasonably standard, but such is >> life). > > For the time being it looks to me that the only sensible thing to do is > to just remove the WK2 API so that the port builds and then find a way > to provide a replacement. Not an elegant solution but this is the brave > new world we live in! >
The solution for the EFL port was to remove the dead bits - including one of our public APIs - and also skip some unit tests. Probably the same idea applies for the GTK port + move the code that depends on WKPageResourceLoadClient to a injected bundle. Br, _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
