Hello all, On May 26th, I sent an email titled "curious about how people would feel about moving to github." While there were a few concerns raised, everyone was generally positive and were mainly concerned that this transition would need to be done carefully with clear workflow instructions and an clearly marked master repository. Since then David Cournapeau has done a lot of work looking into how to make the transition go as smoothly as possible. He has written a script to convert the svn repository to a git repository. And I've registered a numpy organization account on github. Over the next week, David, Stefan, and I will set things up so that everyone can see how things will work after the transition to git. David will convert the current trunk to a git repository and put it on the github site. We will write up instructions on how to use git and the github site. Everyone who wants to can get a github account and test out the workflow. At that point everyone can provide feedback and we can decide if we are ready to move forward. If we are ready to move forward, we will set up a date for the transition. On that date, we would turn off the old subversion account and create a new git repository which would from the point forward be the new master branch. If the transition to git and github for numpy goes smoothly, we will turn our attention to scipy. During the SciPy conference in Austin, we had a Birds-of-a-Feather to discuss the transition to git and github. [[ Here is a picture of the git/github BOF (several people joined the discussion later including Travis Oliphant and Fernando Perez): http://www.flickr.com/photos/irees/4750650877/sizes/l/in/set-721576242721316... ]] At the end of the discussion there was a general consensus that it was time to make the move. Several questions and concerns were raised: 1. Since there are many possible workflows, it is important to clearly document are proposed workflow. This document should provide simple cut-and-paste commands necessary to get developers up and running with git. 2. The question was raised about how to handle bug reports. It was pointed out that while our current trac bug report system isn't perfect, it does work and people are used to it. We decided to keep our existing trac instance and integrate it with the github site. Potentially moving from trac to another system like redmine was brought up, but most people felt it was better to only change one thing at a time (and besides that no one volunteered to do the work necessary to move to a new bug tracking system). 3. Since Ralf Gommers is in the middle of making a release, did he want us to delay any transition preparation until he was finished. This is Ralf's response when Stefan van der Walt contacted him: "Thanks for asking! For me the sooner the better, I do everything with git and haven't touched svn since I discovered Mercurial while writing my thesis (and that feels like a long long time ago)." When Stefan contacted Ralf, Ralf raised the following additional concern: 4. "The two things I haven't seen a good solution for are the svn/externals in scipy which pulls in doc/sphinxext from numpy, and the vendor branch." In response, Stefan asked whether submodules would provide a solution. David Cournapeau responded to Stefan stating "submodules are very awkward to use." Then David added in response to Ralf's original query: "For vendor, it will be a separate repo, and there is no need for synchronization, so that's easy to deal with. For the sphinx extension, I would just merge with the subtree strategy from time to time from a separate repository. "That's what I do for bento + yaku: yaku has its own repo, and when I update the copy in bento, I just use git merge -s subtree --no-squash, so everything is updated in one commit. "The big advantage is that there is no need to even be aware of the second repo for users (git clone will bring everything), and there is no chance of screwing things up: http://book.git-scm.com/5_advanced_branching_and_merging.html" Best, Jarrod