[SciPy-dev] The future of SciPy and its development infrastructure

[Travis E. Oliphant]

Stéfan van der Walt wrote:
> Hi Travis
>
>   
>> 3) There are pieces of SciPy that need work (interpolate stands out most
>> in my mind right now).    I have changes to the interpolate code that I
>> have not yet committed because I was waiting for the release of 0.7 but
>> I really want to commit.  Who is interested in reviewing this?
>>     
>
> I'd be glad to.  Pauli's suggestion of codereview.appspot.com sounds
> good, since we don't have any better infrastructure in place.
>   
As I've mentioned.   I'm all for others doing this if it helps them feel 
more comfortable contributing to SciPy.    I'm not interested in using 
this tool because of the increased effort.   I have always been and 
remain very interested in reviews / feedback / comments / fixes to 
check-ins that I make to the trunk.   If the check-in email is not 
sufficient for large changes, I am willing to send an email to 
interested parties about changes that have been made pointing to the svn 
diff in the Trac.  If someone else would like to take those changes and 
have a discussion with some other tool, that is also fine.   

I'm very impatient because my windows of time to work on something are 
small and if I have to "wait-for-review" before something gets 
checked-in, I suspect I will get impatient because it increases the 
mental-time I have to spend on getting something fixed / improved in 
SciPy.    I'm very aware of many of the improvements that need to be 
made, but don't have a lot of time to spend on them.
>> 4) Bug-fix commits are a different thing than feature-enhancement
>> commits.   We should have different expectations of them.
>>     
>
> I agree, to an extent.  I think it is an ideal opportunity to add a
> test (since, clearly, the current test suite didn't catch the problem,
> and since you had to study the broken code in order to fix it); but in
> such a case it's more important to have the bug fixed.  Unfortunately,
> without a test you won't be absolutely certain that it's fixed
> everywhere, but the process at least converges in the right direction.
>   
I agree, but would mention that a unit test only lets you test against 
that particular feature/bug that was called out in the test.   Without 
code-coverage you don't have any guarantees or even a guarantee that the 
unit-test is written well-enough to catch the more subtle and harder to 
replicate bugs.    So, yes, unit-tests are good, but they are not a 
panacea to the goal of quality code.

>> 6) I very much appreciate all the work people do on SciPy.    I think
>> our biggest lack more than anything else is the "full-time" person that
>> can respond to the user community and keep the momentum moving.
>>     
>
> Absolutely.  I've often wondered how hard it would be to obtain such
> funding, but to date I haven't made any proposals.
>   
Right now it looks to me that we have a steady-stream of students, 
academics, and the dedicated Robert Kern.  I was hopeful that I would be 
able to make SciPy-growth work while I was in academia but it didn't 
work out for me.    Right now, I'm excited to continue to help Enthought 
in its support of SciPy.  I'm hopeful that will lead to me having more 
time to spend on SciPy myself, but it's possible that it won't work out 
that way.    It's great to see others  that have stepped up and are 
continuing to step up to move SciPy forward.

Best regards,

-Travis