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
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
