[webkit-efl] Moving the EFL WebKit2 public APIs to outside WebKit2 directory

[Alexis Menard]

On Wed, Jan 23, 2013 at 5:30 AM, Dominik Röttsches
<dominik.rottsches at intel.com> wrote:
> Hi again,

Hi,

>
> I've gone back to thinking that moving files out of this directory is an
> attempt to modify, if not work around the review policy.
> Thinking this forward in a slightly exaggerated way: What stops Apple
> Reviewers from putting an Owners file into any directory that builds on top
> of Wk2 API.
> What I want to illustrate: Our aim is to have an easier time getting reviews
> for Wk2 EFL specific patches - so, I'd say:
>
> 1) Let's go back and discuss this with Apple reviewers - can we relax the
> policy for the subdirectories? And looking at it from the other way: What
> does it gain us to expedite reviews at the cost of losing experienced
> WebKit2 reviewers feedback?
> 2) Is it really going to be such a bottleneck to work inside the Wk2/
> directory? - In my experience, an informal review + a final review from one
> of the Owners doesn't take unbearably long. It's maybe one day longer than
> landing things in platform/graphics/cairo or platform/network/soup where I
> can receive fast reviews from GTK people for example. - What is your
> experience, what are the examples of having been significantly blocked?
> 3) For red bots we have TestExpectations files where we can mark tests as
> failing and address the underlying issue.
>
> Currently, I don't think it's a good idea to do such a move. In the end, I
> believe we are more productive when cooperating with Apple reviewers, not
> work around them.

Yesterday I spend sometime talking with an Apple employee and also
spend some time thinking about it myself.

I proposed our ideas and we talked a lot.

At the end I don't think moving send the right message, in fact I'm
pretty sure they don't want us to move out.

One thing we should do to avoid breakage is to port as much as we can
our code to use the WebKit2 C API to avoid big breakage (ewk_view is
full of example).

So far the review time slowness is to be proven, it seems that not so
many patches were actually pure Qt, pure EFL or pure GTK so it was
touching the common parts with Apple. It means that in any case we
would have to go through an Owner to get in no matter where half (or
more) the code sit.

It seems their main focus is security and performance for WebKit2.
Maybe instead of trying to workaround the reviewership we should
instead help them where they need, to regain trust and maybe have
someone promoted as an "Owner". Both topics are interesting for us.
Let's land our seccomp patch, the sandbox one and let's find
volunteers to work on improving IPC or memory usage there for example.
We could also see it that way, what if Apple decided to stop using
webkit.org WebKit2/ and work on a private one closed in an internal
repo (and dump the code after), *we* would have to maintain WebKit2/
and improve it so let's do it instead and stop thinking "it's fine
there is Apple to take care of it".

Regards.

>
> Dominik
>
>
> _______________________________________________
> webkit-efl mailing list
> webkit-efl at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-efl



-- 
Software Engineer @
Intel Open Source Technology Center