This is awesome! I love github. I really wanted to champion for its use at the BoF but unfortunately missed it.
--Josh On Tue, Jul 13, 2010 at 6:20 PM, Jarrod Millman <mill...@berkeley.edu> wrote: > 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-72157624272131693/ > ]] > > 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 > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion