[OpenLayers-Dev] Potential move to GitHub

[Eric Lemoine]

On Saturday, February 26, 2011,  <christopher.schmidt at nokia.com> wrote:
> 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.


Hi

Thank you Chris. Moving the trunk to Github sounds great to me. But we
indeed need to find a solution for the sandboxes. Keeping them in the
current SVN repo, and having some doc/tutorial explaining a working
workflow for sandbox development, could be a possibility. As far as
the ticket system is concerned, I think I'd also like to continue
using Trac. But providing links to Git commits in tickets would
probably mean long URLs, there may be Trac plugins to deal with such
things (<http://trac-hacks.org/wiki/GitPlugin>).

Cheers,