Collaboration (was Re: [webkit-dev] Pulling together on WebKit Mobile)

Mike Emmel mike.emmel at
Fri Jan 11 23:13:01 PST 2008

On Jan 11, 2008 1:26 PM, Mark Rowe <mrowe at> wrote:
> On 12/01/2008, at 07:55, Mike Emmel wrote:
> > I'd like for it to be very easy to contribute a git tree with commit
> > rights that was acceptable to the WebKit community
> > would make it very easy to create branches for bug fixes and and as a
> > work area.
> > And it makes it easy to allow outstanding patches to track the head.
> >
> > I found the current process of submitting a patch having the head
> > change breaking the patch resubmitting
> > etc etc to be clumsy.  If the patch was on a git tree that matched the
> > head the branch then then applied.
> >
> > I feel the workflow for patch submission could be made a lot easier
> > with this approach.
> > Especially for complex issues.
> The process you describe is vague and untested in the context of
> WebKit.  The process we have now works reasonably well ("well enough")
> for a large number of developers.  There are some situations, none of
> which are particularly common, in which it is less efficient than it
> could be: two or more developers working together to implement a
> single feature is the one that springs to mind.  Addressing these
> situations is clearly desirable, but I don't believe it's as simple as
> saying that git will magically fix things.  It brings with it a new
> set of problems that most WebKit developers are not familiar with, and
> is much slower than SVN when interacting with an SVN repository, and
> currently has poor Windows support.  Adopting git in a semi-"official"
> manner like you mention would require improving tool support and
> documentation such that any WebKit developer could deal with the new
> workflow if needed.  In itself, this is not a small task.

Why ?
If they want to use it they can if they prefer svn then they should work to get
commit rights. I prefer that a small number of developers have commit rights
to the main svn like it is now. This is far less than the number of developers
that can contribute to webkit and forcing them to work with patches is
simply cumbersome.

Webkit is a fairly sophisticated piece of code using git for daily
development is
trivial. I'd expect any developer who was collaborating on webkit would also be
capable of learning git.

Something as simple as this is sufficient.

Or maybe even this ?

> > I've got other small projects I'd like to share with others before
> > they are ready to submit to the mainline.
> > And more important if others are interested I'd like to see what they
> > are working on without having to discover
> > git repos scattered randomly about the internet.
> A minimal-effort solution could be to use <> ,and
> create a wiki page to catalogue the locations of git repositories that
> other developers are using.  A quick glance shows that Holger has a
> repository on, and there appears to be a GNUstep port
> hosted there too.  As best I can tell, this light-weight approach
> would fulfil your immediate need.

I take it you did not look at that repository that carefully.

I tried this over a year ago and found that your incorrect in your
assumptions about the suitability.

Also having the GNUSstep port and it looks like a number of other WebKit
related projects "lost" over on a generic server is not a good thing.

A collaboration under would bring these projects back
under where they belong.

> > For me having this sort of work area would be very useful.
> I don't disagree that it would be useful.  Part of the point of Git is
> that it is distributed in nature.  This allows individuals to use git
> if they desire, and to experiment and come up with a workflow that
> fits with the existing WebKit tools and processes.  Once tools have
> improved and a common idea of the right workflow to use has evolved,
> we should consider looking into adopting Git more "officially".

Why wait your now officially supporting git via svn tracking.
A clone server that allows developer to create common working areas
is a small step. I'd say you have already done most of the work.
I'd suspect that members of the open source community would be willing
to help with git issues if they arise. Also the tool is used for a lot of large
open source projects most if not all of is under git.
And I'd say that X11 development alone is at least as complex as webkit
not to mention linux kernel development.  Given that you already support a git
server and that large open source projects are successfully using git
I think the
argument your making is weak at best.

Back to immediate needs. For the Gtk-OSX work it has one very useful feature
it would be the only port that could be trivially switched between
freetype rendering
and ATSUI for fonts. Having a version of webkit that could be flipped
between two
"standard" font engines is very useful when looking at font related
layout issues.
It would be a good thing to have this but its not something I'd want
to do via patches.
And I'd would like some help on it.  Its also a good example project
where gtk/osx
or cairo/osx developers would probably want checkin rights but are not
willing to work
to get "official" WebKit contributor rights. WebKit simply is not the
primary project these people
are working on. However I think they would support Gtk/Webkit on OSX
as a primary application
for the Gtk/OSX port.

Another immediate need is if you did this I'd like to ask Pleyo to
move there development over
to this new open git server. Pleyo has done some fairly innovative
work but they have diverged
from the main tree and it would take time and effort to take some of
there ideas and adopt them
to the mainline code base. I'm not speaking for Pleyo but its a shame
that their work has no easy
way to make it back into the mainline development tree.

You found the gnustep project and I'm sure others are floating around
that would be willing to
to use and official git repository. The QT development would probably
be willing to move if
given a chance.  WXwindows work would probably also move.

Thats a fair number of projects that if asked would probably commit to
using a central
git server and they exist right now and all could benefit from easy
access to each others
development trees.

Your webkit ports list has none of this work listed.

Your QT port does not have the git working repository linked in a
obvious manner if at all.

Often open source project end up with pretty strange ports some
important and some niche
support these sorts of efforts is part of running a open source
project in my opinion.

Stuff like this.

I see no reason to have this stuff scattered across the internet.  Why
can't offer
to host these ports ?

More information about the webkit-dev mailing list