[SciPy-dev] The future of SciPy and its development infrastructure
Stéfan van der Walt
Thu Feb 26 06:17:07 CST 2009
2009/2/26 Travis E. Oliphant <email@example.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