[Numpy-discussion] update on the transition to git/github
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 <email@example.com> 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):
> 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:
> NumPy-Discussion mailing list
More information about the NumPy-Discussion