[Numpy-discussion] update on the transition to git/github
Charles R Harris
charlesr.harris at gmail.com
Tue Jul 13 23:15:48 EDT 2010
On Tue, Jul 13, 2010 at 8:20 PM, Jarrod Millman <millman at 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"
>
>
One thing that we need to be clear about is handling line endings in text,
i.e., linefeeds only. I have read tales of folks on windows finding many of
their files showing up as modified on that account. There are ways to deal
with it -- the details escape me at the moment -- but we need instructions
on setting up git on windows so there aren't any problems.
How should we handle commits during the next week or two? I have a few
things I want to get in before 1.5 is tagged.
Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20100713/30b83510/attachment.html>
More information about the NumPy-Discussion
mailing list