On Thu, Nov 11, 2010 at 2:08 PM, Pauli Virtanen <pav@iki.fi> wrote:
On Thu, 11 Nov 2010 12:38:53 -0700, Charles R Harris wrote:
> I'd like to open a discussion about the steps to be followed in merging
> the numpy refactor. I have two concerns about this. First, the refactor
> repository branched off some time ago and I'm concerned about code
> divergence, not just in the refactoring, but in fixes going into the
> master branch on github. Second, it is likely that a flag day will look
> like the easiest solution and I think we should avoid that.

What is a "flag day"?


It all goes in as one big commit.
 
> At the moment it seems to me that the changes can be broken up into
> three categories:
>
> 1) Movement of files and resulting changes to the build process.
> 2) Refactoring of the files for CPython.
> 3) Addition of an IronPython interface.
>
> I'd like to see 1) go into the master branch as soon as possible,
> followed by 2) so that the changes can be tested and fixes will go into
> a common repository. The main github repository can then be branched for
> adding the IronPython stuff. In short, I think it would be usefull to
> abandon the teoliphant fork at some point and let the work continue in a
> fork of the numpy repository.

The first step I would like to see is to re-graft the teoliphant branch
onto the current Git history -- currently, it's still based on Git-SVN.
Re-grafting would make incremental merging and tracking easier. Luckily,
this is easy to do thanks to Git's data model (I have a script for it),
and I believe it could be useful to do it ASAP.


I agree that would be an excellent start. Speaking of repo surgery, you might  find esr's latest project of interest.

<snip>

Chuck