[SciPy-dev] Scipy workflow (and not tools).
Thu Feb 26 10:45:38 CST 2009
On Thu, Feb 26, 2009 at 8:35 AM, Charles R Harris
> On Thu, Feb 26, 2009 at 9:31 AM, Ondrej Certik <firstname.lastname@example.org> wrote:
>> On Thu, Feb 26, 2009 at 5:55 AM, Alex Griffing <email@example.com> wrote:
>> >> I'm another long-time lurker who's been thinking about contributing for
>> >> a while but who's been a bit uncertain about where to start. These
>> >> discussions, plus the git branches Pauli has created, are encouraging
>> >> me
>> >> greatly to roll up my sleeves and delve in.
>> >> Cheers,
>> >> Gareth.
>> > Hi I'm also mostly a lurker. Here's a story about the time I tried to
>> > contribute to scipy.
>> > Maybe a year ago I wanted a procedure to attempt to optimize some aspect
>> > of a multidimensional function. I found scipy.optimize, but the
>> > procedure that I tried failed by dividing by zero. Undaunted, I started
>> > digging in the scipy source code, finding the error in the broyden2
>> > function. The problem was that the algorithm was finding the correct
>> > solution in fewer than the default number of iterations and was dividing
>> > by an error term that was zero.
>> > I sent an email to a scipy mailing list saying that this function needed
>> > some kind of check to see if it was done (error near zero) so that it
>> > could stop iterating so that it would not divide by zero. I got a reply
>> > saying that I needed to write a patch that included the fix to the
>> > function and a new test that used to fail but that now passes. So I
>> > simplified my failing code, I changed the broyden2 function in a way
>> > that I thought would fix the problem, and I sent the code to the mailing
>> > list. I got a reply saying that what they meant by a patch was an svn
>> > diff.
>> > So I installed svn and I checked out the scipy code with the idea that I
>> > could change my local copy, test my changes, and send the diff to the
>> > mailing list. After spending some time trying to get this working, I
>> > stopped for the following reasons:
>> > 1) Binary format and path problems were causing me grief.
>> > 2) I already had a scipy that worked, and I didn't want to break this.
>> > 3) Neil's comment:
>> > """
>> > If I want to make a change, I have to check out the trunk and then
>> > develop my change *completely without the benefit of version control*.
>> > I am not allowed to make any intermediate commits while I learn my way
>> > through the coding process. I must submit a fully formed patch without
>> > ever being able to checkpoint my own progress. This is basically a
>> > deal-breaker for me.
>> > """
>> Hi Alex,
>> it was my who was trying to help you with this. The problem was, that
>> people who have svn access to scipy (e.g. I don't) are very busy, and
>> do you must submit your patches in a way so that it is easy for them
>> to apply it. I agree that git is much easier to use for that, but imho
>> it's not difficult to create a patch with svn as well, especially if
>> you have a working scipy on your computer.
> Do you want SVN access?
I had it in the past, but I forgot how to login, or maybe it stopped
working, I don't know. In any case I much prefer to send patches that
are properly reviewed and then applied by someone who is working with
the scipy tree on a daily basis (as opposed to me who only
occasionally sends a patch). And Stefan did a great job with this. So
this is a hint to Alex ---- just send a nice patch that works and
Stefan will apply it.
The only thing that doesn't work with this scenario is that my name
will not appear on the nice plot that Travis was showing at euroscipy
(and I think at scipy2008 too). But once we move to git, all the names
of the contributors will be preserved. Then I don't see any reason why
people like me should have push access --- I just publish my branch at
github, Stefan pulls it and pushes it in.
More information about the Scipy-dev