[webkit-dev] Large Source Reorganizations By External WebKit Ports

[Peter Kasting]

On Thu, May 19, 2011 at 9:09 AM, Charles Pritchard <chuck at jumis.com> wrote:

> I think Brent's question to the list may have some merit if looked at from
> a different perspective.
> Let me try it... Peter: Are there any lessons learned about that process
> Chromium went through?
>

Darin Fisher shared most of the valuable information here.

In Chromium's case, we were forced to fork due to secrecy constraints during
our initial development -- something which none of us liked from an
engineering perspective, but which I suspect tends to apply to a large
number of ports.  As a result, we became focused on making changes in a
minimally invasive way, to lower the cost of merging.  The consequence of
this was a much higher later upstreaming cost, as "the minimally invasive
way" and "the right way" are frequently not the same.

Additionally, we froze our fork before our first public release, and didn't
unfreeze until almost ten months later.  This added another burden to the
unforking process.

It took something like a year of time and a large amount of engineering
effort to unfork.  However, the alternative of staying forked forever incurs
a perpetual cost on the development team, in addition to being worse for
WebKit as a whole (due to the upstream codebase not truly reflecting ports'
needs and other ports not benefitting from each port's work).  As a result,
I think any company that intends to have a long-lived product based on
WebKit is making a grave mistake if they don't dedicate significant
engineering time to unforking, costly as that is.

PK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110519/9d8d24f7/attachment.html>