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

[Darin Fisher]

On Wed, May 18, 2011 at 2:35 PM, Ojan Vafai <ojan at chromium.org> wrote:

> On Wed, May 18, 2011 at 2:25 PM, Brent Fulgham <bfulgham at gmail.com> wrote:
>
>> Hi Peter,
>>
>> On Wed, May 18, 2011 at 2:09 PM, Peter Kasting <pkasting at google.com>
>> wrote:
>> >> Google used this same approach with their Chromium port, the side
>> effects of
>> >> which find us in year two (or three?) of the effort to merge those
>> >> changes back into the core WebKit archive.
>> >
>> > Um, what?  The Chromium port is fully upstreamed and has been for some
>> time.
>> >  I'm not sure what you're saying here.  We are not forked and in fact
>> have
>> > no support for building Chromium with anything other than upstream
>> WebKit.
>>
>> I admit that statement was a bit hyperbolic; however the Chromium
>> source base was significantly reorganized when it was a 'secret'
>> project, and took a lot of time to get in sync.  I'm wondering why
>> Google, EA, and others have felt the need to do so.
>>
>> Note that there are still things that are not fully merged:  e.g.,
>> FontPlatformData is still largely forked from the mainline
>> implementation (e.g., arbitrarily different names for members).
>
>
> AFAIK, Chromium didn't actively reorganize the source tree. The source tree
> changed out from under us while we were still a private project. This is
> just a natural side effect of not being part of the mainline source tree.
> Stuff moves around (and it should!) as it makes sense to structure the files
> differently.
>
> Chromium's tree not tracking the move is just oversight in some cases.
>
> Ojan
>


we also learned some lessons the hard way.  i wish we had created a webkit
API from day one, to help insulate webcore better from chrome.  we did
create a layer of insulation (called webkit/glue), but it was way too
squishy and not kept clean.  it was a bit painful to untangle that into a
proper API.

we also didn't go with a vendor branch approach in the beginning.  instead,
we maintained forked files in a mirror tree, which just did not scale as the
number of forked files grew (due to V8 integration mainly).  but yeah,
things like the creation of FrameLoader really caused us to spin our wheels!
;-)

-darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110518/30164a68/attachment.html>