[OpenLayers-Dev] Potential move to GitHub
christopher.schmidt at nokia.com
christopher.schmidt at nokia.com
Sat Feb 26 05:51:33 EST 2011
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
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
More information about the Dev