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
