[OpenLayers-Dev] GitHub straw poll

[christopher.schmidt at nokia.com]

On Apr 16, 2010, at 7:22 PM, ext Tim Schaub wrote:

> Hey-
>
> In advance of our infrastructure meeting (time TBD), I thought I'd  
> take
> a poll for the heck of it.
>
> Would people be in favor of or opposed to moving the OpenLayers
> repository to GitHub?

(I'm going to respond in general re: DVCSes here -- if we were to go  
with Git, I would personally prefer to go to OSGeo and get Git + Trac  
set up there, than to migrate to GitHub.)

I feel that moving to GitHub decentralizes community, and (similar to  
a wiki for documentation) causes users to feel 'unconnected' with a  
mainline management of the code.

In many cases, I have felt that the only reason that contributors have  
worked to contribute their changes back to OpenLayers is because of  
the 'cost of forking' -- creating a fork takes time and effort, and  
not doing so is easier than doing so. As a result, they are required  
to participate in the community, and in doing so they have a positive  
effect on the whole community.

By making forking 'easy', we encourage developers to live in their own  
world, with low cost to them, and low incentive to contribute back to  
the community.

In general, I have found that maintaining an SVN repository synced  
using Git has not been so extraordinarily difficult that it's a major  
problem; it is still a cost, but a reasonably low one.

I realize that this is mostly a selfish point of view, but I fear  
making it easy for organizations to fork, whether it be big or small.  
THe motivation to contribute back to OpenLayers is reasonably small  
already, due to the turnaround time on OpenLayers mainline commits;  
moving to Git to me feels like simply giving up.

Our development model (with sandboxes) has generally provided an open  
way for non-committers to have in-SVN access; although we don't use  
these tools much, I think that in general, we could use these much  
more like git. (For example, making everyone who has a trac account  
able to create a sandbox -- something that I've wanted to set up, but  
not made the time for yet.) The merging story with SVN has improved  
with each release, to the point that it is now practical to use SVN  
merge in a way similar to git's merging process. Merging patches could  
be done via svn merge, maintaining history, rather than via the  
somewhat clunky patch-review system we currently have, if we were  
comfortable with a 'looser' mainline branch.

There are some positive effects to be had by having code available in  
a DVCS, but I feel that they are mostly to consumers of the OpenLayers  
project, and especially those who would rather maintain their own copy  
than contribute back to trunk. Following that path to me feels very  
much like 'giving up' on the mainline development of OpenLayers; I  
would rather find flaws and improve the current way we do things than  
go the route of moving to Git.

> If we go with GitHub, we may or may not want to use their issue  
> tracker.
>  This is a separate topic for discussion (the github-trac plugin can
> allow some integration of Trac and GitHub).

Just for the record, there have been several discussions of providing  
Git or mercurial via OSGeo infrastructure. If OpenLayers were to  
desire to make this change, I would make it a priority to do this on  
OSGeo infrastructure if the community so-desired.

> I'm interested mainly to hear if people are generally in favor or
> opposed to the idea of a repository move - and a move specifically to
> GitHub for hosting.

I am not in favor of moving to Git, and if we were to move, I would  
rather move to OSGeo than to GitHub.

Best Regards,
-- 
Christopher Schmidt
Nokia