[OpenLayers-Dev] MOTION: move to GitHub

[christopher.schmidt at nokia.com]

On Sep 17, 2011, at 12:54 PM, Schmidt Christopher (Nokia-S/Boston) wrote:

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

Given the broad support for this from the core developers, and the code sprint
this weekend, I have gone ahead and implemented this change while I had the 
time available. 

As of now, the correct place to commit to OpenLayers is the OpenLayers github
at:

  https://github.com/openlayers/openlayers

All OpenLayers core committers have commit access.

Please continue to follow the same general policies -- close messages, trac
tickets where appropriate, etc. -- as before, but for source commits, commit
to OpenLayers.

(If for some reason someone feels strongly about this change and we need to
go backwards, we can do so.)

-- Chris

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