[webkit-dev] WebKit Wishes

[Eric Seidel]

*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).


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.

*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130130/01ff0e80/attachment.html>