[Numpy-discussion] update on the transition to git/github
Tue Jul 13 21:20:42 CDT 2010
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):
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
"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:
More information about the NumPy-Discussion