[SciPy-dev] The future of SciPy and its development infrastructure
Travis E. Oliphant
Thu Feb 26 13:39:47 CST 2009
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.
More information about the Scipy-dev