[OpenLayers-Dev] Potential move to GitHub

[christopher.schmidt at nokia.com]

Hi,

This week, when working with OpenLayers, I found myself several
times wishing that I had been more amenable to a switch to git as
the primary revision control for OpenLayers. After some discussion
with other developers, it seems we may be in a position where 
a potential shift might be the right direction to go.

Our sandboxes have been a pretty strong success; using the sandbox
mechanism to publish examples was of great use to the developers
who were attending the code sprint in Lausanne. It saved many
people from having to set things up on their own servers, etc.

But SVN's poor merging story makes working across these branches,
and pulling changes from branches back to trunk, much more difficult
than it should be. Our approach to accepting patches also means that
we lose history of some developments (or at least make it harder to
trace).

In the past, I've argued against git for several reasons:

 1. It's all sharp edges. Anyone who uses git can probably tell
    you horror stories of how they've cut themselves before on
    some corner of git. This affects new developers who are unfamiliar
    with OpenLayers and git the most, and other developers somewhat.

 2. I worry that distributed development could mean fewer people working
    to interact with trunk. Making it easier to maintain your own branch
    makes it less likely that you would need to push changes back 'upstream',
    and I feel like there are a number of cases where I have run into people
    who have gotten stuck on older versions of OpenLayers for that reason.

 3. It has a tendency to hide development behind closed doors, whereas 
    our sandboxes currently encourage development in the open. 

Although all of these are still concerns from my point of view, I think that
there are some ways to mitigate them, and I think that once that happens,
the benefits overcome the potential losses.

 1. Use GitHub. GitHub is a well-connected, widely used component; it is
    used by many people who are already using git. It is an excellent
    tool which helps to minimize some of the rough edges around git. 
    In addition, it has support for a (simple) SVN proxy to Git, that
    will allow people who have workflows around SVN to maintain some
    of that existing workflow for checkouts/diffs and the like.
 
 2. Continue to maintain an OpenLayers sandbox repository, which deploys
    code from sandboxes to a location on the web. (This may actually get
    significantly more complex if we use git as designed, so we'll see
    if this actually makes sense in the end.) In general, having a 
    centralized location to put things you want to share with other
    people is a big win for new functionality.

 3. Encourage the use of forks on GitHub (instead of people simply cloning
    and developing without pushing to a public server). I hope that this
    type of social encouragement will cause us to not have a lot of forked
    development far from OpenLayers.

The network tracking feature in GitHub seems very powerful, and if people
working with the OpenLayers source code can use GitHub to publish their
work, I think that gives us a solid direction to go for maintaining a solid
picture of "who is doing what". GitHub also offers strong repository 
browsing, an impressive set of tools for easily making small changes, etc.
I would still like to continue using trac (instead of 'pull requests') for
our management, but am completely supportive of managing actual commits 
to master based on pulling commits rather than patch files.

I'll admit that I'm not well versed in git, and I expect this might be a
rough transition. I also don't really like the idea of making an open 
source project somewhat dependent on a closed source tool, but that's
ideological, and I don't think I should let my ideology get in the way
of doing what is best for the project.

My hope is that Git will make it easier for people working on external
projects to push changes back to the upstream project, make developers
more able to support cross-collaboration in feature development, and will
make some of the simpler changes more easy for interested developers
to implement and report without a significant startup cost. In the '3.0'
branches on GitHub, we saw many of these benefits -- we got several
pull requests from previously uninvolved developers in the first weeks --
and I hope that using distributed development like this would help us
more going forward.

If you have specific concerns, questions, or thoughts on this, I'd love
to hear them. Objections, suggestions, or different directions are also
welcome.

-- Chris