[webkit-dev] Ports and Forks

[Mike Emmel]

On 2/15/07, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Feb 15, 2007, at 7:01 AM, Mike Emmel wrote:
>
> > Lately it seems a lot of people working on various ports forks and
> > other variants of webkit have become more vocal.
> >
> > The problem is that most of the work is not readily accessible to the
> > webkit community because it is stored in private repositories. This
> > makes the sharing of concepts ideas and code difficult.
> > I understand the need to keep a robust functional head for stable
> > webkit development but wonder if it would be possible to set up a
> > solution for allowing all the other work going on with webkit to be
> > made available.
> >
> > I would like to propose the following.
> >
> > Secondary repositories are created per major project. As these
> > projects mature or fix bugs that are in the head or even make
> > structural changes that are of interest the code is migrated and
> > brought into the main repository.
>
> Anyone is welcome to set up their own public repository, but we would
> instead recommend using the main public repository, using an SVN
> branch if necessary. This also makes it easy to merge between
> branches if needed.
>
> > A number of tools exist for tracking a SVN repository with a second
> > repository.
> >
> > I use git and git-svn.
> >
> > I favor git/git-svn over other tools since it allows the secondary
> > repositories to work as peers
> > making it easy to share code amongst branches before committing to the
> > main repository.
> > The advantage is that the branches and forks can be normalized to
> > reduce the amount of conflicting patch submissions for the main
> > repository.
> >
> > Next since git is peer to peer multiple git repositories for each
> > variant are easy to create.
> >
> > Other approaches are possible.
> >
> > And example use case would be to add E4X support to WebKit the most
> > interesting approach is integration of tamarin into webkit since this
> > would provide both a jit and E4X.
> >
> > 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).
>
Thats the biggest reason to set up sister repositories it allows work to be
done and shared and the desirability to be determined over time.
Worst case is that a project to integrate tamarin flushes out a number of
bugs in the existing implementation even if the project never makes it
mainstream.
Certainly it would result in understanding and maybe changes to allow pluggable
js engines for WebKit this would also be a positive result without the main work
being merged.

As you see  it also opens up a chance to pick and choose parts
of a project that could go into the main repository. In general most
of the work may never be integrated or may integrate over a long
period of time or only the concepts may make it with the
implementation changed radically. In the above example if a clean
plugin api is developed their is no reason for the project to be
tightly bound to the main
webkit builds.


Next a central SVN repository does not solve the problem.
Most people would like to keep their main repository hosted locally.
And push upstream at periodically. In many cases SVN is block by firewalls
etc. Federated repositories solve this problem. Git itself was created
for exactly this reason. Other ways to solve the problem exist
including federated SVN tools.

Then of course other topics such as related projects etc could be addressed.

Other approaches such as a sourceforge like system for webkit related
projects are possible.

Cluttering the main svn repository even if its on branches is probably
not a good idea.

Finally even doing a wiki page that allowed people to mention their
projects and provide urls would be good it does not even require
hosting of the repositories.

And if this is too much just a page with a small description and link
to the related project would be useful.

Example

I'm using webkit for ....
Here is a link to my project ....

The current wiki page requires some sort of registration with a svn server.

http://trac.webkit.org/projects/webkit/wiki

And the page is quite messy.

Just having a submission form for projects would help.
I don't  want  edit rights to the wiki.

So simply putting a related projects link on the front page and a
simple submission from
along with hopefully a better organized catalog of related work is enough.

I just would like to know a bit more about what people are doing with
webkit in particular about forks and ports of webkit itself.







> Regards,
> Maciej
>
>