[webkit-dev] WebKit Wishes

[Eric Seidel]

On Wed, Jan 30, 2013 at 1:57 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> Hi Eric,
>
> These are great thoughts. I agree with you on all points. One informative
> comment below:
>
> On Jan 30, 2013, at 1:28 PM, Eric Seidel <eric at webkit.org> wrote:
>
> I wish we only had one build system (it were easy to add/remove/move files).
>
> I believe changes like http://trac.webkit.org/changeset/74849 are an
> unhealthy sign for the project.  Adam is not the only person who has chosen
> to empty files instead of removing them.  The pain of updating 8 build
> system is so great, we jump through hoops to avoid it.  Which means it took
> us months to move JavaScriptCore/wtf to WTF, and will take us years to kill
> WebCore/platform.
>
>
> I wish I felt like reviewers understood/trusted each other more.
>
> I’ve worked at both Apple and Google.  The WebKit community is full of
> brilliant engineers.  Yet I frequently feel a lack of trust in my (or
> others) judgement, or witness hot-headed remarks on bugs, lists or IRC.  I
> don’t think it’s that people don’t trust me after nearly 8 years (!?) on
> this project, but rather that we forget, or fail to communicate trust among
> ourselves.  Social problems are perhaps harder to solve for us technical
> types, but I worry that for many of us it’s just become “us” and “them” and
> we’ve stopped trying.
>
>
> I wish it were easy to work on feature branches.
>
> We have no good solution for features.  For one-patch features, you do them
> on your own.  For larger, you maybe use github or most likely you just land
> on trunk behind a #define.  None of these have worked well.  Some of this is
> the limits of SVN, but it should be trivial for someone to work on a new
> feature a long time, w/o endangering trunk or having massive merge pain
> every day.  Other projects can do this.  So should we.  This is both
> impeding progress, and destabilizing trunk.
>
>
> 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 wish that the tree always built and tested cleanly.
>
> Other (much larger) projects than WebKit accomplish this.  Yet somehow
> Google pays 2 full-time engineers to watch our bots and yet we fail.  I know
> other companies do similar.  Automated rollouts is one solution.
> Branched-based development, or trybots are others.  But at the size and
> scale we’re at now, every minute of a broken tree, is 100x or more minutes
> of potentially lost developer productivity.
>
>
> I wish I felt like I could follow what was going on (and trust WebKit to
> guard the web, instead of depending on Apple or Google).
>
> We’re the leading browser engine, with hundreds of committers, any of whom
> can add an API to 50% of internet browsers with a single commit.  I wish we
> had a public process for feature/web-api review.  I wish I felt like both
> major companies were willing participants in such.  (Google has an internal
> process, but it sees limited use, in part because it’s powerless -- a ‘yes’
> from our process is not a ‘yes’ from WebKit.)  I want to feel like I can
> better observe and participate in the development of our web-api (and trust
> that it’s being done well!) without scanning every changeset just to be able
> to comment post-facto.  (This is also reflected in the fact that the
> features enabled by the major Apple or Google ports are wildly different,
> with seemingly little rhyme or reason.)
>
>
> I wish WebCore was not trapped by Mac WebKit1’s legacy designs.
>
> WebKit2 is obviously a step towards the future.  But until we can kill the
> Widget tree, the insanely fragile loader complexity, and the limits imposed
> by the least-common-denominator on classes like ResourceRequest, we’re still
> trapped in the past. One of the things I’ve learned in working on Chromium,
> is that we were wrong many years ago to fold our platform abstraction
> (Qt-implementation) and khtml into one library.  In a sand-boxed
> multi-process world, the rendering library is just a hunk of code running
> the same on every platform.  And platform code has no place in our core
> engine code (aka WebCore).
>
>
> In designing WebKit2, we tried to avoid some mistakes in the WebKit1 Mac API
> design (such as exposing the underlying network library, exposing our NSView
> hierarchy as part of the API, and giving too much salience to frames). While
> we can't remove those parts of the API entirely, if we get more Mac API
> clients onto WebKit2, then the performance of these details of the WK1 API
> becomes less critical, and we can simulate them in ways that have lower
> performance but also less impact on WebCore.

Do you have any pie-in-the-sky guestimates as to when in the future we
may be able to release ourselves from WebKit1 API constraints (through
this current WK2 path)?

1 year? 5 years? 10 years?


> 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 think we need to work together to bring about some of these dreams, for
> the short and long term health of the WebKit project.
>
> Thank you for listening.
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>