[OpenLayers-Dev] Potential move to GitHub

[Greg Troxel]

<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.

>  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.

I have seen quagga and gpsd (both projects where I have commit access)
move to git, and seen two outcomes.  In gpsd, the culture is very much
that official master is what counts, and things have been good.  In
quagga, the code is such that producing very-high-quality changes is
extraordinarily hard, and there are a several git repos with
not-100%-baked changes (plus the maintainers have not had enough time to
really cope).  But even in what I consider an extreme case of not merged
changes -- speaking as one who has permission but not spare time to
resolve/merge the changes -- I'm really glad we have git.

>  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 run a large project at work where there is no permission to contribute
issue; people either work on it and can or don't work on it.  People
wanted to have personal git repositories, on the same server as the
official repo.  I said no, and work is done on feature branches (which
are about the feature, not the person) and then merged when
ready/reviewed/tested/etc.

> 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.

Agreed.

>  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.

>  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.

>  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.

> 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.

Agreed.

> 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)

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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20110226/4a8a9634/attachment.bin