[webkit-dev] Re: Ports and Forks
mjs at apple.com
Fri Feb 16 00:58:08 PST 2007
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
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.
More information about the webkit-dev