[OpenLayers-Dev] Potential move to GitHub

[christopher.schmidt at nokia.com]

On Feb 27, 2011, at 3:15 AM, ext Greg Troxel wrote:
> <christopher.schmidt at nokia.com> writes:
> 
>> 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.
> 
> True, but by now most people in the open source world have had to learn
> it, so I think you're right that nowish is a good time to move.

I think "most" is an exaggeration. But I think "The majority of the people who are
likely to become long term OpenLayers committers" probably is true --
since half of the trunk committers are using git-svn, I feel relatively
safe on that front :) 

>> 3. It has a tendency to hide development behind closed doors, whereas 
>>    our sandboxes currently encourage development in the open. 
> 
> I don't think that's really true.  git lets you do many things, but
> individuals can publish their repositories, and many do.   The nice
> thing about git (hg/bzr/darcs) is that you can decouple permission to
> commit to official repo with being able to really use the tool.

I think that this is a 'fear' rather than a concern based in fact; it's
definitely emotional rather than data-driven, since I've never seen any
data on it. I also have that fear less now that I've seen less things which
end up in sandboxes forever -- and even those things would likely have
been fixed easier if our merging tools were not based around a version
control system which is hostile to merging :)

>> 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.
> 
> I have found, as a casual not-quite-contributor to guile, which switched
> to git several years ago, that learning enough git to just get the code
> and update it was really easy.
> 
> I would suggest looking at gitorious too.  GitHub seems well done, but
> I've heard concerns expressed that it is a closed-source website.   Some
> other project I follow (sorry, can't remember what) has had similar
> discussions and chose gitorius.

Nokia is a strong Gitorious supporter, so I have considered using it for 
several different projects. I have consistently found that many of the
features that make git less painful that I care about are only on GitHub.
Importantly to me personally is the network browser, which (since
Git doesn't have it built in) is dependent on people being on the same
host: at that point, GitHub simply has a bigger network effect, because
more developers already use it. 

In addition, as you pointed out elsewhere, unlike SVN, where we chose
to end up is more flexible: once we move from SVN to git, moving from
GitHub to Gitorious is an easy move; in fact, even maintaining both
is trivial. I personally have (as I said) idealogical complaints about
GitHub not being open source: I would feel the same way if, for example,
we went with a non-open source build tool. However, since its inception,
OpenLayers *has* used a non-open source build tool, and it hasn't killed
anyone yet :) (Though it did slow packaging for RedHat and Debian.)

>> 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.
> 
> I would expect branches in an oficial repo, rather than master in many
> repos.

Right, the OpenLayers sandbox repo would be an official one; anyone
can ask for push permission and get it, and it is a fork of master. I
don't actually know how this would work, but that's the idea I have anyway.
I expect some people would still simply fork OL directly, rather than come
to us and asking for access, but hopefully that would be relatively minimal.

>> 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.
> 
> Sure, or at least encourage people to put up their repo and have a
> list.  I did something like that in quagga which has a README.hacking
> giving URLS of repos.

Anything that requires maintenance from people with access to master is
doomed to failure ;) But good to know that other people have tried that;
still, I think a big win of GitHub is this automatic tracking.

>> 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.
> 
> Well, I can see that, but Linus started down this bath with bitkeeper
> and here we are...  (hence my suggestion to check out gitorious)

The primary problem with Gitorious is that maintaining a list of actively
developed forks in a way that others can see it requires active core
developer maintenence (or even non-core developer maintenance). Anything
that we can get rid of in that vein, I think will be better for the 
project overall.

But I'm happy to do our best to maintain a full clone on gitorious; I think
that becomes as simple as a cronjob if we switch to GitHub in the first
place (as you say below).

> At least the dependency on closed-source tools is soft; people will have
> full repo clones so even if github vanished it would be annoying but not
> a real problem.
> 
>> 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.
> 
> My experience is that being able to stay within the tool across the
> authorized-committer/random-hacker boundary is worth a lot (which is I
> think what you're saying).

Yep, I think that's my hope as well.

Thanks for the feedback!

-- Chris