[OpenLayers-Dev] MOTION: move to GitHub

[christopher.schmidt at nokia.com]

On Sep 16, 2011, at 3:04 PM, ext christopher.schmidt at nokia.com wrote:

> 
> On Sep 16, 2011, at 2:48 PM, ext Tim Schaub wrote:
> 
>> I'd like to propose we move the trunk to GitHub.  If other agree, we
>> could maintain a read-only svn mirror at the current URL.  And, the
>> sandboxes could stay as they are.  The only consequence of this move
>> would be that trunk committers use git instead of svn.
>> 
>> I'm +1 on this change.
>> 
>> Andreas is traveling, but he told me he was +1 on it as well.
> 
> I'm +0. Do we have an idea of how we want to make the move? Do you anticipate
> wanting to move tags, branches, etc. over as well? (My understanding when
> I looked was taht this makes things... hard.) 

Okay, so:
 1. Moving svn to git is hard, but doable; I'm working on that part.
 2. We'll move project/ (website), doc/ and trunk as three seperate
    github projects under the OpenLayers organizations. 
 3. Sandboxes will continue to live in SVN if people want to use them.
    We'll also write up docs as to how to achieve sandbox-like live
    deployments using github forks/gh-pages instead, if people would
    rather use git. We won't automatically deploy github forks to 
    dev.openlayers.org like we do sandboxes.
 4. trunk examples are easy.
 5. Releases shouldn't be much different; we'll have to modify our tools 
    to do things like switching branches/making tags/ etc. in the git
    way, but there's nothing super-complex here.
 6. We will maintain pushing all of trunk commits from git to SVN.
 7. We won't push branch or tag commits back to SVN after the switch.
    This means that for future releases, if you want to actually check
    out the code, you'll need to use git rather than SVN. Given that checking
    out from a specific tag is a relatively minor use case, I'm not
    concerned we're screwing that many people here. (The actual releases will
    obviously continue to be available.)

Still open questions: 
 - Github can't do commit emails with diffs. (A diff *link* is included, but no
   diff, like:

 Branch: refs/heads/djangozoom
 Home:   https://github.com/crschmidt/olhttp

 Commit: 2676cc08a8ce5274f272bd81c6d6314efad0a1e9
     https://github.com/crschmidt/olhttp/commit/2676cc08a8ce5274f272bd81c6d6314efad0a1e9
 Author: Christopher Schmidt <crschmidt at crschmidt.net>
 Date:   2011-09-17 (Sat, 17 Sep 2011)
)

If people are dependent on the diffs, we'll have to do something else; otherwise,
we can just go ahead with making commit posts go to the commits list without much
further work.

We'll also need to set up a hook from github to ping OpenLayers when commits 
are made so that we can do the mirror step to the OL repo; Eric has been working
on that, and I think it's just the web/hook side now.  

Overall, I think that all the major pain points are easily resolvable without 
major work. I think the release engineering bits are totally doable, and I'm
no longer worried about them. 

-- Chris 

> I don't have any idea how to manage branching for releases and the like
> in github; do others have an idea of how these kinds of things are supposed
> to work? 
> 
> I'm worried about release engineering approaches; other than that, I have
> no major concerns, and I'm sure that others can help me understand how 
> these things are supposed to work and how they will be reflected in the 
> SVN repository from the Git repository.
> 
>> Tim
>> 
>> -- 
>> Tim Schaub
>> OpenGeo http://opengeo.org/
>> Expert service straight from the developers.
>> _______________________________________________
>> Dev mailing list
>> Dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/openlayers-dev
> 
> _______________________________________________
> Dev mailing list
> Dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/openlayers-dev