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

[Charles R Harris]

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>