[webkit-dev] Announcing new port: Nix

[Hugo Lima]

On Fri, Sep 13, 2013 at 4:31 PM, Antonio Gomes <tonikitoo at webkit.org> wrote:
> So will you advocate your users to use your external GitHub version or
> the one in
> WebKit?
>
> Please consider not being half upstream.

It wont be half upstream, but the github repository will be for
example a fallback for a working bleeding edge Nix just in case of
WebCore changes that break Nix on webkit.org. We can also push things
first there then on webkit.org if a faster development pace if needed,
as all Nix developers use git this also means that experimental
feature branches will exists on github repo too (don't tell me about
create svn branches).

The worst scenario is if a WK2 change doesn't get accepted at all, but
I don't think gonna happen if the change isn't wrong.

In other words, no, it's not our intent to do half upstream like IIRC
happened with Blackberry port.

> On Fri, Sep 13, 2013 at 2:37 PM, Hugo Lima <hugo.lima at openbossa.org> wrote:
>> 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
>>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev