[Numpy-discussion] update on the transition to git/github

Joshua Holbrook josh.holbrook@gmail....
Tue Jul 13 21:50:41 CDT 2010

This is awesome! I love github. I really wanted to champion for its
use at the BoF but unfortunately missed it.


On Tue, Jul 13, 2010 at 6:20 PM, Jarrod Millman <millman@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

More information about the NumPy-Discussion mailing list