[webkit-dev] WebKit Wishes

Eric Seidel eric at webkit.org
Sat Feb 2 22:47:58 PST 2013


On Wed, Jan 30, 2013 at 2:11 PM, Xan Lopez <xan at gnome.org> wrote:
> Hi Eric,
>
> On Wed, Jan 30, 2013 at 10:28 PM, Eric Seidel <eric at webkit.org> wrote:
>> I wish we didn’t have to worry about platforms we couldn’t test.
>>
>> It can’t be the job of the core maintainers to care about all the peripheral
>> ports which contribute very little core code. Our code needs to be
>> structured in such a manner that its easy for the core to march forward,
>> while letting the ports catch up as they need to asynchronously.  Platform
>> support code shouldn’t even need to be in webkit.org!  Porting webkit.org’s
>> platform abstractions should be trivial, but core developers (which probably
>> 90% of them use only 2 ports Mac WK2 + Chromium Linux) shouldn’t need to
>> worry about keeping all ports working.
>
> I agree this is a hard problem. Also a stressful situation to get
> oneself into. Coming up with ways to allow port code to survive core
> changes would be excellent for everyone, even for the "small ports"
> people who hack on the core and also cannot easily test Mac WK2,
> Chromium Linux or any other port.
>
>>
>> I write less out of pain, and more out of hope for the future.  I believe
>> all of these are solvable problems, but I believe we need the will to solve
>> them.  Apple’s recent announcement of WebKit2 lockdown is clearly one
>> attempt at some of these.  But for the other 50% of WebKit developers who
>> don’t work on WebKit2, locking down WebCore is not a good solution.
>
> I agree the WebKit2 lockdown is one attempt at solving this, but
> hopefully we can agree it's not a particularly innovative one.
> Breaking builds and allowing bugs to pile up while they are fixed is a
> nasty situation, one that historically we have tried really hard to
> avoid for very well known reasons. I understand in the final analysis
> allowing the core to move fast could be more important than having an
> healthy ecosystem of minor ports without huge teams behind them, but I
> really hope that this is only a temporary solution and that in the
> future we'll be able to find better solutions like those that you
> suggest in your email.
>
> Also, on a personal note, I've been around for enough years to
> remember the time when people trying to get ports started were eagerly
> welcomed by Apple employees, who would go out of their way to help us
> get started, review our patches when we had no reviewers in our team,
> patiently explain this or that part of the code, etc. I made sure to
> tell everyone I knew that WebKit was one of the most well managed open
> source projects in existence, one of those rare combinations of
> success and fidelity to some of the best values that open source
> supposedly represents. It is with a bit of sadness that years later I
> find that the same project (even the same people) now has a very
> different attitude, and that long term contributors who I believe have
> modestly helped to make this project more robust and popular are
> mostly seen as part of a problem instead of as part of its thriving
> community. I suppose wild success has some unfortunate costs.

I would like to say that I agree with you.  I also have been around
long enough to remember days of helping new ports come to WebKit. :)

And I would argue that our current situation is all our own fault.
We've provided ports poor APIs to port with.  WebCore/platform is
nice, but as I've learned from Chromium, it's *way* too low a level to
hook into.

I believe that for WebCore/WebKit to be long-term successful, that
WebCore needs to know *nothing* about the platform that it's running
on.  That it should be completely abstracted from the outside world.
Right now we're no where close to that, and thus any major change in
WebCore requires changes and testing on all of our ports.

If WebCore had only one true-way to talk to the outside world, than I
believe we'd have a much easier time making large architectural
changes, and I believe that individual porting communities would have
a much easier time of maintaining their builds/tests.

> In any case, I don't want to end on a pessimistic note. I'm sure
> there's enough brilliance in this community to come up with better
> solutions for everyone, including future ports that do not exist yet
> but that might be very relevant in this world that moves at breakneck
> pace.
>
> Cheers,
>
> Xan


More information about the webkit-dev mailing list