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

Stéfan van der Walt stefan@sun.ac...
Thu Feb 26 06:17:07 CST 2009

Hi Travis

2009/2/26 Travis E. Oliphant <oliphant@enthought.com>:
> 1)  We absolutely need to improve the quality of SciPy, and that does
> mean more tests, documentation, and reviews --- and most importantly
> faster releases.    Right now, a release happens when someone steps up
> to be a release manager and commits to making it happen.    I don't know
> how to promise that on a regular cycle with only volunteer effort.    I
> would love to have the resources to fund SciPy release management.

If the release process wasn't so painful, maybe more people would volunteer?

> 2)  I think we are doing a decent job of commits having tests and
> documentation.    We should continue to remind each other of the need
> for quality code in SciPy (and continue to clean up code that is there).

I don't want to complain all the time (I really hate complaining),
which is why I want a policy in place.  Policy sounds formal, so let
me rather say: I'd like us to come to a consensus on the type of
changes that are appropriate. If we did, then the term "decent", as
you use it above, becomes more clearly defined.

> 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.

> 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.

> 5) We do have scikits for more experimental additions to live so that
> SciPy should become more of a stable, documentation-rich library.  But,
> the problem there is distribution.   EPD and Enstaller (our BSD-licensed
> version of setuptools) is one answer to that distribution problem.
> There are others.

You guys are doing a fantastic job, keep it up.  Also thanks to Pierre
Raybaut, whose Python(x,y) distribution is making life so easy for our

I don't know if you've visited the portal to SciKits:
http://scikits.appspot.com.  If we can make any changes to facilitate
packaging, let me know.

> 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.


More information about the Scipy-dev mailing list