[webkit-dev] Re: Ports and Forks

[Maciej Stachowiak]

On Feb 15, 2007, at 9:45 PM, Alp Toker wrote:

> Maciej Stachowiak wrote:
>>> By setting up a associated repository this work would be  
>>> accessible to
>>> all interested parties and once stable it could be integrated  
>>> into the
>>> main repository.
>> This is an example of the kind of project that would be better  
>> done on a branch than in a separate repository (if it were  
>> desirable at all).
>
> I have to disagree here. git-svn is really the only tool in its  
> class for working on branches of large svn projects. I haven't  
> spent as much time as Mike hacking on the Gdk WebKit port, but the  
> distributed and transparent form of git repositories does in my  
> experience almost eliminate the pain of merging upstream changes,  
> maintaining history and most importantly providing atomic patches  
> that are suitable for inclusion back into the original repository.

I don't understand how git-svn can possibly be better than a branch  
in the same SVN repository. What does it do that being in the same  
repository doesn't? Note that Subversion has really good support for  
merging between branches.

> The WebKit project would do well to formalise this pattern. It  
> would benefit not only the ports, but also help reduce the barrier  
> for bugfixes to find their way back into the project rather than  
> getting left by the wayside in an svn branch or bug report.

It seems to me that encouraging lots of separate repositories is  
effectively encouraging lots of quasi-permanent forks of the project.

One of the reasons we are encouraging many projects and organizations  
to adopt WebKit is so that, together, we can have a greater market  
share than any of us could individually. This way, web developers  
have to pay attention to our engine when designing their sites. But  
if WebKit is split into dozens of separate fragmented ports, each  
will end up with a whole separate set of bugs and fixes. If making a  
site work in one WebKit-based product doesn't fix it for all of them,  
then web developers will remain unimpressed by our combined market  
share.

This is the reason we are trying to push for more unification rather  
than more fragmentation. We vastly improved WebKit's portability  
architecture over the past year and a half in part so that other  
ports could live cleanly in our tree side-by-side. We have given  
Nokia their own branch in the repository to do with as they please  
and are encouraging them to update to the current tip of tree. We've  
helped Troll Tech integrate the Qt port and are continuing to assist  
them with doing porting work directly on our trunk. And in general we  
try to be supportive of any reasonable changes.

Another thing worth noting is that WebKit development moves at an  
incredibly fast pace. We have hundreds of checkins a week and often  
make very large structural changes for performance and code  
understandability. Trying to track these from a separate repository  
ends up imposing huge merging costs to try to keep up. Or you diverge  
so far that catching up becomes almost impossible.

Overall, I think it is far healthier for the project to strive for  
greater unification than to fragment in many directions. We cannot  
stop anyone from setting up their own private or public repository if  
they choose to. But we strongly encourage others to at least try  
working in the webkit.org repository before going their own way.

Regards,
Maciej