Re: [webkit-dev] Large Source Reorganizations By External WebKit Ports
On 5/18/11 2:09 PM, Peter Kasting wrote: On Wed, May 18, 2011 at 12:36 PM, Brent Fulgham bfulg...@webkit.org mailto:bfulg...@webkit.org 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. And as a web app developer, I've been happy to push bug fixes into WebKit via Chromium bug reports. I heard from RIM that they're working hard to get their fork back in line with WebKit upstream; they've contributed a lot of work to WebKit upstream, but are not yet merged back in... That's what I heard. 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? As a coder, I certainly see that fork and merge process as a normal process -- a company forks from the upstream, works on the code base within their own product, and at some point their use becomes mature and they're able to merge back in with the upstream. Are there any insights to that process -- or even estimates -- such as -- it took us x months once we had WebKit working for us, to get back to building directly with the upstream. Little bits of information like that may be helpful to some WebKit vendors. -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Large Source Reorganizations By External WebKit Ports
Speaking from my time at HP/Palm working on webOS, there was always a desire to upstream the project particularly to avoid missing all the source reorganization going on in the main tree. Unfortunately, there's a large bar of entry to upstream a new WebKit port, and we never had the resources to make that happen... On Thu, May 19, 2011 at 9:09 AM, Charles Pritchard ch...@jumis.com wrote: On 5/18/11 2:09 PM, Peter Kasting wrote: On Wed, May 18, 2011 at 12:36 PM, Brent Fulgham bfulg...@webkit.orgwrote: 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. And as a web app developer, I've been happy to push bug fixes into WebKit via Chromium bug reports. I heard from RIM that they're working hard to get their fork back in line with WebKit upstream; they've contributed a lot of work to WebKit upstream, but are not yet merged back in... That's what I heard. 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? As a coder, I certainly see that fork and merge process as a normal process -- a company forks from the upstream, works on the code base within their own product, and at some point their use becomes mature and they're able to merge back in with the upstream. Are there any insights to that process -- or even estimates -- such as -- it took us x months once we had WebKit working for us, to get back to building directly with the upstream. Little bits of information like that may be helpful to some WebKit vendors. -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Large Source Reorganizations By External WebKit Ports
On Thu, May 19, 2011 at 9:09 AM, Charles Pritchard ch...@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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Large Source Reorganizations By External WebKit Ports
I've recently been spending some time reviewing some of the WebKit port that are not part of the core WebKit archive. Electronic Arts, for example, has been very good about making source dumps of their build of WebKit available (wow -- WebKit on the PS3! :), Playo has released their sources, and Valve was kind enough to point me at the version of Chromium they use for their own work. While this transparency is fantastic, I find it depressing that in most cases these porters chose to significantly rearrange the source archive. This makes it difficult to evaluate the changes made to support various custom features, as well as drastically increasing the effort required to integrate these ports into WebKit proper. 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. This phenomenon makes me wonder if we have some sort of deficiency in the layout of the WebKit sources, or the way we specify and link with various external dependencies, that lead new porters to embark on these large reorganizations? I did not find it difficult to work with the existing WebKit layout -- in fact, I find it logical and easy to understand. And certainly several other ports (such as the Windows CE, wxWidgets, Haiku, BEOS, etc.) were able to easily integrate with the existing layout. However, the existence of these several source variations is a clear indication that not everyone finds the source base so easy to work with. Perhaps if we understood the reasoning behind that led to these external source reorganizations we could do a better job presenting suitable API's for porters so that they would not feel the need to take these drastic steps. Can any of you external users share the reasons behind your reorganization efforts? Thanks, -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Large Source Reorganizations By External WebKit Ports
On Wed, May 18, 2011 at 12:36 PM, Brent Fulgham bfulg...@webkit.org 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. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Large Source Reorganizations By External WebKit Ports
Hi Peter, On Wed, May 18, 2011 at 2:09 PM, Peter Kasting pkast...@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). -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Large Source Reorganizations By External WebKit Ports
On Wed, May 18, 2011 at 2:25 PM, Brent Fulgham bfulg...@gmail.com wrote: Hi Peter, On Wed, May 18, 2011 at 2:09 PM, Peter Kasting pkast...@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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Large Source Reorganizations By External WebKit Ports
On Wed, May 18, 2011 at 2:35 PM, Ojan Vafai o...@chromium.org wrote: On Wed, May 18, 2011 at 2:25 PM, Brent Fulgham bfulg...@gmail.com wrote: Hi Peter, On Wed, May 18, 2011 at 2:09 PM, Peter Kasting pkast...@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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
