[webkit-dev] Announcing new port: Nix

[Hugo Lima]

On Fri, Sep 13, 2013 at 3:00 PM, Anders Carlsson <andersca at apple.com> wrote:
>
> On Sep 12, 2013, at 1:58 PM, Hugo Lima <hugo.lima at openbossa.org> wrote:
>
>> On Thu, Sep 12, 2013 at 4:14 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>>> Interesting. That sounds a lot like Chromium's WebKit API layer.  If I
>>> remember correctly, that layer had to be modified constantly as
>>> WebCore/WebKit code was refactored so I'm a bit worried about this.
>>
>> Yes, in fact we got some API from them.
>
> This is my biggest concern with the Nix port; that it will end up exposing implementation details of our platform layer, making it harder for us to perform sweeping changes to said layer (for example, like what Darin is doing with his pasteboard cleanup patches).
>
> In fact, it reminds me of the WebKit2 situation (before we instituted the build policy) where some changes that should in theory take days would end up taking weeks because of:
>
> - Churn waiting for the EWS bots to do their thing.
> - Churn due to patches being rolled out for breaking other ports (due to certain build flags being enabled in said ports).
> - Churn due to patches being rolled out for breaking other ports (due to misconceptions about the correct WebKit2 semantics in said ports).
>
> Maybe we would need a similar build policy for WebCore?
>
>>> But it sounds like you're suggesting that Nix port's maintainers will be
>>> responsible for making any code changes necessary to support
>>> WebCore/WebKit/WebKit2 refactoring?
>>
>> Yes, this is the idea, is our concern to keep our code working.
>
> I am glad to hear that. Does that mean that we’re allowed to break the Nix port without having patches rolled out by members of the Nix team?

This already happen nowadays, so it would not change too much our
development. Even after nix upstream process we will probably keep a
copy on github with few additional patches that may not fit on e.g.
WebKit2 or need to be landed a bit faster on our tree due to some
customer needs.

I didn't talk with other team members about it, but IMO it's not a big
deal to break it on these kind of WebCore changes that affect all
ports, I'm saying this because the chance of having these patches
breaking other ports as well is considerable too, besides if the
change get announced on this ML before get landed we'll have enough
time to adapt to it.

> - Anders
>